Antes de escribir una sola línea de código, conviene tener claro de qué hablamos cuando decimos "microservicios". El término se usa con tanta ligereza que muchas veces se aplica a sistemas que no lo son (un monolito troceado en varios procesos, por ejemplo) o se confunde con tecnologías concretas como Docker o Kubernetes. En esta primera lección vamos a fijar una definición de trabajo, repasar las características que distinguen de verdad a un microservicio, entender de dónde viene esta forma de construir software y acordar el vocabulario que usaremos durante todo el curso. Cerraremos con un primer vistazo, deliberadamente sencillo, a cómo se vería la tienda online de TechCorp dividida en servicios.

Esta lección es la base conceptual sobre la que se apoyan las demás: no hablaremos aquí de si los microservicios son buenos o malos (eso llega en la siguiente lección), ni de cómo se comparan en detalle con un monolito, ni de cuándo conviene adoptarlos. Aquí solo respondemos a la pregunta "¿qué es exactamente un microservicio?".

1. Qué es un microservicio (y qué no lo es)
2. Características definitorias
3. Breve historia: de SOA a los microservicios
4. Vocabulario básico del curso
5. Primer vistazo: la tienda de TechCorp dividida en servicios
6. Errores comunes y consejos
7. Ejercicios
8. Conclusión

Una definición de trabajo, suficientemente precisa para todo el curso:

Un microservicio es un componente de software autónomo, que implementa una capacidad de negocio bien delimitada, que se despliega de forma independiente, que posee sus propios datos y que se comunica con el resto del sistema únicamente a través de interfaces bien definidas (APIs o mensajes).

Y una arquitectura de microservicios es un sistema compuesto por varios de esos componentes colaborando entre sí para ofrecer una aplicación completa.

Fíjate en que la definición no menciona ninguna tecnología. No dice "contenedores", ni "Kubernetes", ni "REST", ni "Node.js". Todas esas herramientas aparecerán en el curso porque facilitan enormemente el trabajo, pero no son lo que define a un microservicio. Se pueden tener microservicios sin contenedores y se pueden tener contenedores sin microservicios.

Es tan importante saber lo que no es como lo que es. Estas situaciones se confunden a menudo con microservicios:

Una regla práctica: si no puedes desplegar el componente sin coordinarte con otro equipo, o si no puedes cambiar su esquema de datos sin avisar a nadie más, probablemente no tienes un microservicio, sino un trozo de algo más grande.

El "micro" no se refiere a líneas de código. No existe una cifra mágica ("menos de 500 líneas"). Se refiere a que el servicio tiene un alcance funcional pequeño y bien definido: hace una cosa de negocio y la hace completa. Un servicio de pagos puede tener miles de líneas y seguir siendo un microservicio perfectamente razonable; lo que importa es que su responsabilidad es clara y que se puede razonar sobre él sin necesidad de entender todo el sistema.

Las siguientes siete características son las que, juntas, distinguen a un microservicio. Cuando evalúes un sistema, pregúntate cuántas de ellas cumple realmente.

El servicio puede funcionar, cambiar y evolucionar por sí mismo. Tiene su propio código, su propio ciclo de vida y sus propias decisiones internas. La autonomía es la característica raíz de la que derivan casi todas las demás.

Cada servicio se construye, se prueba y se pone en producción por separado, sin necesidad de desplegar el resto del sistema. Si el equipo de Pagos corrige un error, sube una nueva versión de servicio-pagos y nadie más se entera. Esto exige que las interfaces entre servicios sean estables y estén versionadas (lo veremos en el módulo 3).

Los servicios se dividen siguiendo el negocio, no las capas técnicas. En TechCorp hablamos de "catálogo", "pedidos" o "pagos", no de "servicio de base de datos", "servicio de lógica" y "servicio de interfaz". Un servicio contiene todo lo que necesita para cumplir su capacidad: su API, su lógica y su almacenamiento.

Esto es una diferencia importante respecto a arquitecturas por capas donde se separaba "el back-end de datos" del "back-end de negocio": ahí una funcionalidad nueva obligaba a tocar todas las capas y a coordinar a todos los equipos.

Cada servicio es dueño exclusivo de sus datos. Nadie más lee ni escribe directamente en su base de datos; si otro servicio necesita esa información, la pide a través de la API o la recibe mediante eventos. En TechCorp, el catálogo vivirá en MongoDB y los pedidos en su propio PostgreSQL, y servicio-pedidos jamás hará un SELECT sobre la colección de productos.

Esta característica es la más costosa de cumplir cuando se viene de un monolito, y le dedicaremos una lección completa en el módulo 2.

Los servicios se comunican a través de la red usando protocolos sencillos y bien conocidos: normalmente HTTP/REST para peticiones síncronas y mensajería (en nuestro caso RabbitMQ) para eventos asíncronos. La inteligencia está en los servicios, no en la infraestructura de comunicación. Se suele resumir con la frase smart endpoints, dumb pipes ("extremos inteligentes, tuberías tontas").

Un servicio pertenece a un equipo que lo diseña, lo construye, lo despliega y lo opera ("you build it, you run it"). Ese equipo es responsable de que funcione en producción. En TechCorp, el equipo de Luis será dueño de servicio-pedidos de principio a fin.

Con muchos servicios pequeños es inviable hacer despliegues a mano. Los microservicios presuponen integración y despliegue continuos, infraestructura como código, pruebas automatizadas y monitorización. Sin automatización, la arquitectura no escala operativamente.

Los microservicios no aparecieron de la nada. Son la evolución de ideas anteriores, corregidas por la experiencia.

En los años 2000, las aplicaciones empresariales se construían mayoritariamente como monolitos: una única aplicación grande desplegada en un servidor de aplicaciones. A medida que crecían, se volvían difíciles de mantener y de escalar.

Como respuesta surgió la SOA (Service-Oriented Architecture, arquitectura orientada a servicios). La idea era buena: dividir el sistema en servicios reutilizables. Pero la implementación habitual tenía problemas:

• Los servicios se comunicaban a través de un ESB (Enterprise Service Bus), una pieza central que enrutaba, transformaba y orquestaba mensajes. El ESB acabó siendo un cuello de botella técnico y organizativo: toda la inteligencia estaba ahí.
• Los protocolos (SOAP, WS-*) eran pesados y verbosos.
• Los servicios solían compartir bases de datos y desplegarse de forma coordinada.
• La gobernanza era muy centralizada: comités que decidían qué servicios existían y cómo eran.

Hacia 2011-2014, empresas como Netflix, Amazon o SoundCloud empezaron a contar públicamente cómo habían dividido sus sistemas en servicios muy pequeños, autónomos, con equipos propios y comunicación por HTTP. En 2014, James Lewis y Martin Fowler publicaron el artículo que popularizó el término y fijó las características que hemos visto en el apartado anterior.

Varios factores hicieron posible este enfoque en ese momento:

En cierto sentido, los microservicios son "SOA bien hecha": mantienen la idea de servicios pero eliminan el ESB centralizado, los protocolos pesados, la base de datos compartida y la gobernanza rígida.

A lo largo del curso usaremos estos términos constantemente. Aquí solo damos definiciones breves; cada uno se desarrollará en su lección correspondiente.

No hace falta memorizar la tabla: la iremos usando y ampliando. Lo importante es que, cuando aparezca uno de estos términos, sepas a qué familia pertenece.

TechCorp es la empresa ficticia que nos acompañará durante todo el curso. Opera una tienda online que hoy es un único monolito en Node.js con Express y una sola base de datos PostgreSQL. La presentaremos en detalle en la lección 01-05; por ahora, veamos únicamente qué aspecto tendría el punto de llegada: la tienda descompuesta en servicios.

Observa varias cosas en el diagrama:

• El cliente no habla con los servicios directamente, sino con el gateway. Los servicios internos ni siquiera necesitan ser accesibles desde Internet.
• Cada servicio corresponde a una capacidad de negocio: clientes, catálogo, inventario, pedidos, pagos, notificaciones. No hay un "servicio de base de datos" ni un "servicio de lógica".
• Hay dos estilos de comunicación: flechas continuas (peticiones síncronas, HTTP) y flechas discontinuas (eventos asíncronos a través de RabbitMQ). Cuando se crea un pedido, servicio-pedidos no llama uno a uno a inventario, pagos y notificaciones: publica un evento y cada interesado reacciona.
• Cada servicio tiene su propio puerto porque es un proceso independiente. En el módulo 4 los levantaremos de verdad.

Para que la idea de "API" deje de ser abstracta, así se vería (en pseudo-HTTP, sin implementar) una parte mínima de lo que servicio-pedidos ofrece al resto del mundo.

Crear un pedido:

Consultar un pedido:

Fíjate en lo que no aparece en estos ejemplos: no hay nada sobre cómo se guarda el pedido, qué base de datos usa el servicio, ni cómo se calcula el total. Quien consume la API solo conoce el contrato: la ruta, el formato de entrada y el formato de salida. Esa opacidad es precisamente lo que permite que el equipo de Luis cambie las tripas de servicio-pedidos cuando quiera sin romper a nadie.

También conviene notar que el pedido se crea con estado PENDIENTE y más tarde aparece como CONFIRMADO. Entre medias han ocurrido cosas en otros servicios (reservar stock, cobrar) de las que el consumidor no se entera directamente. Ese flujo, "un cliente hace un pedido", es el hilo conductor de todo el curso y lo desmenuzaremos en la lección 01-05.

• Confundir la herramienta con la arquitectura. Usar Docker y Kubernetes no convierte un sistema en microservicios. Pregúntate por las siete características, no por el stack.
• Pensar que "micro" significa diminuto. Servicios excesivamente pequeños (a veces llamados nanoservicios) multiplican la comunicación y el coste operativo sin aportar autonomía real. El tamaño correcto lo dicta la capacidad de negocio, no un límite de líneas.
• Dividir por capas técnicas. Un "servicio de acceso a datos" y un "servicio de lógica" no son microservicios; son un monolito partido por la mitad que obliga a desplegar ambos a la vez.
• Compartir la base de datos "solo al principio". Es la forma más habitual de acabar con un monolito distribuido. Si dos servicios comparten tablas, en la práctica son uno.
• Ignorar la parte organizativa. La propiedad por equipos y la automatización no son detalles opcionales; sin ellas la arquitectura no se sostiene. Lo veremos con más detalle en la lección 01-04.
• Consejo: cuando leas sobre un sistema "de microservicios", intenta identificar cuál es su unidad de despliegue y quién es dueño de cada dato. Esas dos preguntas desmontan la mayoría de las falsas afirmaciones.

Para cada situación, indica si describe un microservicio y justifica con al menos una de las siete características.

1. TechCorp despliega su monolito actual en cuatro servidores idénticos detrás de un balanceador de carga.
2. El equipo de Marketing crea una pequeña aplicación independiente en Python que gestiona cupones, con su propia base de datos, su propia API REST y su propio pipeline de despliegue.
3. El equipo de Pedidos extrae la lógica de pedidos a un proceso Node.js separado, pero este sigue leyendo y escribiendo directamente en las tablas productos y clientes de la base de datos del monolito.

Relaciona cada frase con el término del vocabulario que describe:

• a) "Cuando se confirma un pago, se publica un mensaje para que quien lo necesite reaccione."
• b) "En Black Friday levantamos ocho copias del servicio de catálogo."
• c) "Todas las peticiones de la app móvil entran por el mismo sitio, que decide a qué servicio enviarlas."
• d) "Documentamos las rutas, campos y códigos de error de la API de pedidos y nos comprometemos a no romperlos."
• e) "Podemos ver que la petición pasó por tres servicios y en cuál se perdió el tiempo."

Siguiendo el estilo de los ejemplos de pseudo-HTTP de la lección, escribe dos endpoints que podría exponer servicio-catalogo: uno para consultar un producto por su identificador y otro para listar productos filtrando por categoría. Indica método, ruta, un ejemplo de respuesta y el código de estado. No implementes nada; se trata solo de pensar en el contrato.

Ejercicio 1

1. No. Es el mismo monolito replicado. La unidad de despliegue sigue siendo una (falla el despliegue independiente) y todas las réplicas comparten código y base de datos (falla la descentralización de datos).
2. Sí. Cumple autonomía, despliegue independiente, capacidad de negocio propia (cupones), datos propios y API ligera. Además, ilustra la heterogeneidad tecnológica: puede estar en Python aunque el resto sea Node.js.
3. No (todavía). Aunque es un proceso separado, accede directamente a datos de otras áreas. Es un monolito distribuido en miniatura: cualquier cambio en productos o clientes puede romper este proceso, y viceversa. Para ser un microservicio debería obtener esa información a través de las APIs o eventos de catálogo y clientes.

Ejercicio 2

• a) Evento (y por extensión, broker de mensajes).
• b) Instancia (varias instancias del mismo servicio).
• c) Gateway (API Gateway).
• d) Contrato.
• e) Traza distribuida (observabilidad).

Ejercicio 3 (una solución posible)

Puntos a valorar: rutas basadas en sustantivos (/productos), uso de GET para consultas, filtros por query string, respuesta con paginación y un 404 Not Found (no mostrado) si el producto no existe. Todo lo relativo al buen diseño REST se desarrolla en la lección 03-01.

En esta lección hemos establecido la definición de trabajo de microservicio: un componente autónomo, centrado en una capacidad de negocio, desplegable por separado, dueño de sus datos y que se comunica por interfaces ligeras. Hemos visto que las siete características (autonomía, despliegue independiente, modelado por capacidad de negocio, datos descentralizados, APIs ligeras, propiedad por equipos y automatización) son las que distinguen a un microservicio, y que ninguna tecnología concreta lo define. Hemos situado la idea en su contexto histórico, como corrección de los errores de la SOA clásica, y hemos fijado el vocabulario que usaremos en adelante. Por último, hemos echado un primer vistazo al mapa de servicios de TechCorp y a lo que significa que un servicio "exponga una API".

Con estos cimientos, la siguiente lección aborda la pregunta que todo el mundo se hace a continuación: ¿qué se gana y qué se paga al adoptar esta arquitectura? Veremos las ventajas y las desventajas de los microservicios ilustradas con situaciones concretas de TechCorp.