Ya sabemos qué es un microservicio. La pregunta natural que sigue es: ¿merece la pena? La respuesta honesta es "depende", y esta lección existe para que ese "depende" deje de ser vago. Vamos a recorrer con detalle las ventajas que ofrece la arquitectura y, con la misma seriedad, las desventajas que trae consigo. Es importante entender ambas caras porque, como veremos, casi cada ventaja tiene un coste asociado: no se obtiene escalado selectivo sin asumir complejidad de red, ni despliegues independientes sin gestionar contratos, ni autonomía de equipos sin invertir en automatización.

Cada punto lo ilustraremos con una situación concreta de TechCorp, la tienda online que sirve de hilo conductor del curso. También presentaremos las célebres "ocho falacias de la computación distribuida", una lista de suposiciones erróneas que todo desarrollador que pase de un monolito a servicios distribuidos acaba descubriendo, a menudo por las malas. En esta lección no haremos todavía la comparación estructurada con el monolito (lección 01-03) ni daremos criterios de decisión (lección 01-04); aquí se trata de entender bien qué se gana y qué se paga.

1. Ventajas de los microservicios
2. Desventajas de los microservicios
3. Las ocho falacias de la computación distribuida
4. Tabla resumen: cada ventaja y el coste que trae
5. Errores comunes y consejos
6. Ejercicios
7. Conclusión

En un monolito, si una parte del sistema necesita más capacidad, hay que replicar toda la aplicación. Con microservicios se escala solo el servicio que lo necesita.

Situación en TechCorp: durante el Black Friday, el tráfico de navegación por el catálogo se multiplica por veinte, pero el número de pedidos "solo" se triplica y las consultas de datos de cliente apenas cambian. Con el monolito actual, Marta tiene que contratar servidores para replicar toda la tienda, incluidos módulos que no están bajo presión. Con servicios separados, se levantan diez instancias de servicio-catalogo y dos de servicio-pedidos, y el resto se queda como está. La factura de infraestructura y el riesgo de sobredimensionar bajan.

Cada servicio se despliega por separado. Un cambio pequeño en un servicio no obliga a reconstruir, probar y desplegar todo el sistema, y por tanto se puede desplegar más a menudo y con menos riesgo.

Situación en TechCorp: el equipo de Luis corrige un error en el cálculo de gastos de envío. Hoy, en el monolito, ese cambio espera al despliegue semanal de los viernes junto con otros treinta cambios de cinco equipos; si algo falla, hay que averiguar cuál de los treinta fue. Con servicio-pedidos separado, Luis despliega el martes por la mañana, en diez minutos, y si algo va mal sabe exactamente qué revertir.

Cada equipo es dueño de uno o varios servicios y decide cómo construirlos, cuándo desplegarlos y cómo operarlos. Se reduce la coordinación entre equipos (reuniones, esperas, dependencias) y aumenta la velocidad.

Situación en TechCorp: hoy, para añadir un campo a la tabla pedidos, Luis tiene que consultarlo con el equipo de Notificaciones (que lee esa tabla para redactar los correos) y con el de Pagos (que la actualiza al cobrar). Con servicios separados, cada uno tiene sus datos y su API: Luis cambia lo que quiera por dentro mientras respete el contrato público.

Cada servicio puede usar la tecnología más adecuada para su problema: otro lenguaje, otra base de datos, otra versión de una librería. Y se puede probar una tecnología nueva en un servicio pequeño sin apostar todo el sistema.

Situación en TechCorp: el catálogo tiene productos con atributos muy variables (una camiseta tiene tallas y colores; un portátil, procesador y memoria). En PostgreSQL eso obliga a tablas genéricas incómodas. Con servicio-catalogo aislado, el equipo puede usar MongoDB, cuyos documentos flexibles encajan mucho mejor, sin que pedidos ni pagos abandonen PostgreSQL. En este curso mantendremos Node.js en todos los servicios por simplicidad didáctica, pero nada impediría que uno estuviera en Go o Java.

Un fallo en un servicio no tiene por qué tumbar el resto, siempre que el sistema esté diseñado para tolerar que una parte no responda.

Situación en TechCorp: el proveedor de envío de correos electrónicos sufre una caída y el módulo de notificaciones empieza a acumular errores y a consumir memoria. En el monolito actual, ese módulo comparte proceso con todo lo demás: la fuga de memoria acaba tumbando también la creación de pedidos, y la tienda entera deja de vender por culpa de los correos. Con servicio-notificaciones separado, los correos se retrasan, pero los pedidos siguen creándose y cobrándose. (Ojo: este aislamiento no es automático; hay que diseñarlo, y lo veremos en el módulo 6.)

Un servicio de unos pocos miles de líneas se entiende, se prueba y se modifica con mucha más facilidad que un monolito de cientos de miles. Un desarrollador nuevo es productivo antes, las pruebas corren en segundos y el código "viejo" se puede reescribir servicio a servicio.

Situación en TechCorp: un desarrollador que se incorpora al equipo de Pagos necesita hoy semanas para entender el monolito antes de tocar nada, porque cualquier función puede tener efectos en cualquier parte. Con servicio-pagos acotado, en un par de días conoce toda su base de código y puede empezar a contribuir con confianza.

Ahora, con la misma honestidad, el precio.

Lo que antes era una llamada a una función dentro del mismo proceso ahora es una petición por la red a otro proceso, que puede estar caído, lento o en otra versión. Aparecen problemas que no existían: tiempos de espera, reintentos, idempotencia, orden de mensajes, versionado de contratos, descubrimiento de servicios. Hay más partes móviles y más formas de que algo falle.

Situación en TechCorp: en el monolito, crearPedido llama a reservarStock y, si falla, el pedido no se crea y punto. Con servicios separados, servicio-pedidos envía una petición a servicio-inventario, no recibe respuesta en tres segundos... y no sabe si el stock se reservó o no. ¿Reintenta y arriesga reservar dos veces? ¿Cancela y arriesga dejar stock bloqueado? Cada una de esas decisiones ahora hay que tomarla explícitamente.

Una llamada dentro del mismo proceso tarda nanosegundos; una llamada HTTP entre servicios, milisegundos, y además puede fallar. Un flujo que en el monolito atravesaba cinco funciones ahora atraviesa cinco servicios y suma sus latencias.

Situación en TechCorp: la página de detalle de un producto necesita el producto (catálogo), el stock disponible (inventario) y las valoraciones del cliente (clientes). Tres llamadas de 20 ms que en el monolito eran tres consultas SQL en el mismo proceso ahora son tres saltos de red, y si uno de ellos tarda 2 segundos, la página entera tarda 2 segundos.

Con una única base de datos, una transacción garantiza que "o se hace todo o no se hace nada". Con una base de datos por servicio ya no hay transacciones que abarquen varios servicios: hay que aceptar la consistencia eventual y diseñar mecanismos de compensación.

Situación en TechCorp: hoy, en una sola transacción SQL, se inserta el pedido, se descuenta el stock y se registra el pago; si el pago falla, se hace rollback de todo. Con tres bases de datos distintas, si el pago falla después de haber descontado el stock, alguien tiene que devolver ese stock explícitamente. Ese "alguien" es un patrón llamado saga, que se estudia en la lección 02-05.

Probar un servicio aislado es fácil; probar que diez servicios funcionan bien juntos no lo es. Y cuando algo falla en producción, el error puede estar en cualquiera de los servicios por los que pasó la petición, cada uno con sus propios logs.

Situación en TechCorp: un cliente se queja de que su pedido aparece como "pagado" pero no le ha llegado el correo de confirmación. En el monolito, se abre un único fichero de log y se sigue la petición. Con seis servicios, hay que buscar en seis sitios, correlacionar por un identificador común y reconstruir la secuencia. Sin trazabilidad distribuida (módulo 6) esto es una pesadilla.

Cada servicio necesita construirse, empaquetarse, desplegarse, monitorizarse, escalarse y protegerse. Seis servicios son seis pipelines, seis paneles de métricas, seis conjuntos de alertas, seis bases de datos con sus copias de seguridad. Además, hacen falta piezas nuevas que el monolito no necesitaba: un broker de mensajes, un gateway, un orquestador, herramientas de observabilidad.

Situación en TechCorp: hoy Marta tiene un servidor de aplicaciones y una base de datos. Mañana tendrá un clúster de Kubernetes, RabbitMQ, cinco bases de datos, Prometheus, Grafana, Loki, Jaeger y un gateway. Alguien tiene que saber operar todo eso, y no es gratis ni en dinero ni en personas.

Los microservicios presuponen equipos autónomos con responsabilidad de extremo a extremo. Si la organización no está preparada para eso (equipos por capa técnica, un único equipo de operaciones al que hay que pedir permiso, decisiones muy centralizadas), la arquitectura choca con la estructura y sale perdiendo la arquitectura.

Situación en TechCorp: hoy existe "el equipo de back-end", "el equipo de front-end" y "el equipo de sistemas". Si se dividen los servicios pero se mantiene esa estructura, cada despliegue de servicio-pedidos seguirá necesitando la aprobación de sistemas y la coordinación con front-end, y la autonomía prometida no aparecerá.

Es el peor de los mundos: la complejidad de un sistema distribuido sin las ventajas de la autonomía. Ocurre cuando los servicios comparten base de datos, cuando hay que desplegarlos todos a la vez porque sus contratos cambian de forma acoplada, o cuando uno no puede funcionar sin llamar síncronamente a otros cinco.

Situación en TechCorp: un intento apresurado de "hacer microservicios" separa el código en seis procesos, pero todos siguen conectados a la misma base de datos PostgreSQL. Resultado: cada cambio de esquema exige coordinar seis despliegues, la red añade latencia y fallos que antes no existían... y no se ha ganado nada. Este riesgo es tan importante que volveremos sobre él en la lección 01-04.

En los años 90, ingenieros de Sun Microsystems (Peter Deutsch y otros) enumeraron una serie de suposiciones falsas que los programadores tienden a hacer cuando empiezan a construir sistemas distribuidos. Décadas después siguen igual de vigentes, y son la razón de fondo de casi todas las desventajas que acabamos de ver.

La lección que dejan es sencilla de enunciar y difícil de interiorizar: al pasar a microservicios, la red deja de ser un detalle y se convierte en parte del diseño. Cada llamada entre servicios debe diseñarse asumiendo que puede fallar, tardar o llegar duplicada.

Esta tabla es probablemente lo más útil que puedes llevarte de la lección. Cada fila enfrenta una ventaja con el precio que hay que pagar para obtenerla de verdad.

Si te fijas, la columna de la derecha describe en buena medida el contenido del resto del curso. Los módulos 3 a 7 existen para pagar, de forma ordenada, los costes de la columna central.

• Contar solo las ventajas. Es el error más frecuente en presentaciones a dirección: se promete velocidad y escalado y se calla el coste de operar quince servicios. Después la realidad pasa factura. Presenta siempre la tabla completa.
• Creer que el aislamiento de fallos es automático. Separar procesos no evita que un servicio caído arrastre a los que dependen de él si estos esperan indefinidamente su respuesta. Hay que diseñarlo.
• Subestimar la consistencia eventual. "Los datos se sincronizarán en unos segundos" suena inofensivo hasta que un cliente ve su pedido pagado y su stock no reservado. Hay que pensar cada flujo con esa posibilidad en mente.
• Adoptar heterogeneidad tecnológica sin necesidad. Que se pueda usar un lenguaje por servicio no significa que se deba. Cada tecnología añadida es un coste permanente.
• Olvidar las ocho falacias. Cada vez que escribas una llamada entre servicios, repásalas mentalmente: ¿qué pasa si no responde? ¿si tarda 10 segundos? ¿si llega dos veces?
• Consejo: cuando alguien proponga "sacar X a un microservicio", pídele que diga qué ventaja concreta de la lista busca y qué coste concreto asume. Si no puede nombrar ambos, la propuesta no está madura.

Para cada situación, indica qué ventaja de los microservicios ayudaría a resolverla y qué desventaja o coste habría que asumir a cambio.

1. En la campaña de rebajas de enero, la tienda entera se ralentiza porque miles de usuarios navegan por el catálogo, aunque compran pocos.
2. El equipo de Notificaciones quiere probar un nuevo proveedor de envío de SMS, pero le da miedo tocar el monolito porque cualquier fallo afecta a la venta.
3. Un despliegue del viernes introdujo un error en pagos y hubo que revertir toda la aplicación, incluidas mejoras del catálogo que funcionaban bien.

Lee este fragmento (simplificado y en pseudocódigo) de cómo un desarrollador de TechCorp podría implementar la creación de un pedido llamando a otros servicios, e identifica al menos tres falacias de la computación distribuida que está ignorando.

Marta debe decidir si TechCorp inicia la transición a microservicios. Redacta, en cinco o seis líneas, un párrafo equilibrado que le presente dos ventajas y dos costes concretos para TechCorp, usando situaciones reales de la tienda.

Ejercicio 1

1. Ventaja: escalado selectivo (replicar solo servicio-catalogo). Coste: operar más instancias, necesitar orquestador y balanceo; y aceptar que el catálogo, al ser un servicio aparte, se consulta por red desde pedidos (latencia).
2. Ventaja: aislamiento de fallos y despliegue independiente (probar el nuevo proveedor en servicio-notificaciones sin arriesgar la venta), además de heterogeneidad tecnológica si el proveedor requiere una librería distinta. Coste: hay que diseñar qué ocurre en pedidos si notificaciones falla, y mantener un pipeline y una monitorización propios para ese servicio.
3. Ventaja: despliegues independientes (revertir solo servicio-pagos). Coste: contratos versionados entre pedidos y pagos para que la reversión de uno no rompa al otro; más pipelines de despliegue.

Ejercicio 2

• La red es fiable: no hay manejo de errores; si cualquier fetch falla, la función lanza una excepción y el estado queda inconsistente (por ejemplo, stock reservado sin cobro).
• La latencia es cero: tres llamadas síncronas encadenadas; el tiempo total es la suma, y no hay tiempo máximo de espera.
• La topología no cambia: las direcciones IP están escritas a fuego; en cuanto una instancia se mueva, todo falla.
• La red es segura: HTTP sin cifrar ni autenticación entre servicios.
• Además, devuelve CONFIRMADO sin comprobar las respuestas, y si el cliente reintenta, se reserva y se cobra dos veces (falta idempotencia, consecuencia de la falacia 1).

Ejercicio 3 (una redacción posible)

Dividir la tienda en servicios nos permitiría, por un lado, escalar solo el catálogo en campañas como el Black Friday en lugar de replicar toda la aplicación, y por otro, que el equipo de Pedidos despliegue sus correcciones cuando estén listas sin esperar al despliegue semanal ni arriesgar el resto de la tienda. A cambio, tendríamos que asumir dos costes claros: la creación de un pedido pasaría a depender de llamadas por red a inventario y pagos, con la latencia y los fallos que eso implica y sin una transacción única que lo deshaga todo si algo falla; y necesitaríamos invertir en infraestructura y conocimiento que hoy no tenemos (orquestación, mensajería, observabilidad) para operar seis servicios en vez de uno.

En esta lección hemos visto que los microservicios ofrecen ventajas reales (escalado selectivo, despliegues independientes, autonomía de equipos, libertad tecnológica, aislamiento de fallos y bases de código manejables), pero que cada una viene con un coste igualmente real: la complejidad de un sistema distribuido, la latencia y los fallos de red, la pérdida de transacciones globales, la dificultad de probar y depurar, el coste operativo, las exigencias organizativas y el riesgo de acabar con un monolito distribuido. Las ocho falacias de la computación distribuida resumen por qué esos costes son inevitables: la red no es fiable, ni instantánea, ni segura, ni estática. La tabla de ventaja frente a coste debería acompañarte en cualquier discusión de arquitectura.

Con las dos caras de la moneda claras, en la siguiente lección haremos una comparación estructurada, dimensión a dimensión, entre la arquitectura de microservicios y la monolítica, y seguiremos un mismo cambio funcional en TechCorp a través de ambas para ver las diferencias en la práctica.