Para entender bien qué aportan los microservicios hay que entender igual de bien aquello con lo que se comparan: la arquitectura monolítica. Es la forma más habitual de construir software, la que usa hoy TechCorp y, probablemente, la que has utilizado en la mayoría de tus proyectos. Lejos de ser una reliquia, el monolito tiene virtudes importantes y, bien construido (el llamado monolito modular), es una opción excelente para muchísimos sistemas.

En esta lección definiremos qué es un monolito y sus variantes, compararemos ambas arquitecturas dimensión a dimensión con una tabla y diagramas, y seguiremos paso a paso el ciclo de vida de un mismo cambio funcional ("añadir cupones de descuento a la tienda de TechCorp") en cada una de ellas para ver dónde están las diferencias reales. Terminaremos desmontando el mito de que el monolito es siempre la opción mala. Aquí no decidiremos todavía cuándo conviene una u otra (eso llega en la lección 01-04) ni veremos la técnica de dividir un monolito (lección 02-02).

1. Qué es un monolito
2. El monolito modular: un punto intermedio
3. Comparativa dimensión a dimensión
4. Los dos sistemas en diagramas
5. Un mismo cambio, dos ciclos de vida: cupones de descuento en TechCorp
6. Otras alternativas: SOA y monolito modular como destino
7. El mito de que el monolito es siempre malo
8. Errores comunes y consejos
9. Ejercicios
10. Conclusión

Un monolito es una aplicación construida y desplegada como una única unidad: un solo proceso (o un solo artefacto que se ejecuta en varios procesos idénticos), un solo repositorio de código habitualmente, y casi siempre una sola base de datos. Toda la funcionalidad (interfaz, lógica de negocio, acceso a datos) vive en el mismo despliegue.

Características típicas:

• Una unidad de despliegue: se compila o empaqueta todo junto y se sube todo junto. En TechCorp, techcorp-shop es un único proyecto Node.js que se arranca con node servidor.js y sirve toda la tienda.
• Llamadas internas en memoria: cuando el módulo de pedidos necesita comprobar el stock, llama a una función del módulo de inventario en el mismo proceso. Nada viaja por la red.
• Una base de datos compartida: todas las tablas (clientes, productos, stock, pedidos, pagos, notificaciones) están en el mismo PostgreSQL y cualquier módulo puede consultar cualquier tabla. Las transacciones abarcan todo lo que haga falta.
• Escalado horizontal por réplica completa: si hace falta más capacidad, se ejecutan varias copias idénticas del monolito detrás de un balanceador.

Es importante subrayar que "monolito" no significa "código desordenado". Un monolito puede estar perfectamente organizado en capas y módulos. Cuando el código de un monolito está enmarañado, sin límites internos claros, se habla de big ball of mud ("gran bola de barro"), que es un problema de calidad, no de arquitectura de despliegue.

Un monolito modular es un monolito cuyo código está dividido en módulos con límites explícitos, cada uno con su API interna y, en la versión más disciplinada, con su propio esquema o conjunto de tablas al que los demás módulos no acceden directamente. Sigue desplegándose como una unidad, pero por dentro se parece mucho a un conjunto de microservicios que viven en el mismo proceso.

El monolito modular tiene un valor doble: es una arquitectura excelente por sí misma, y además es el mejor punto de partida si algún día se quiere migrar a microservicios, porque los límites ya están trazados. Un módulo bien aislado se puede "extraer" a un servicio con relativa facilidad; una bola de barro, no. Volveremos sobre esta idea en el módulo 2.

Esta es la tabla central de la lección. Compara ambas arquitecturas en las dimensiones que más importan en la práctica. Léela con calma; casi cada fila corresponde a una lección posterior del curso.

Una forma útil de leer la tabla: el monolito es sencillo al principio y se complica al crecer; los microservicios son complicados al principio y mantienen la complejidad acotada al crecer. La cuestión de dónde está el punto de cruce es exactamente lo que abordaremos en la siguiente lección.

Todo vive en el mismo rectángulo. Las flechas entre módulos son llamadas a funciones. Todos los módulos apuntan a la misma base de datos.

Cada servicio tiene su propio rectángulo y su propia base de datos. Las relaciones entre servicios pasan por la red (HTTP o RabbitMQ). El gateway es el único punto de contacto con el exterior.

Nada ilustra mejor las diferencias que seguir un cambio real. Marta pide una funcionalidad nueva: cupones de descuento. Un cliente introduce un código al hacer el pedido, el sistema valida el cupón, aplica el descuento al total y registra que el cupón se ha usado. Además, se debe poder consultar en el catálogo qué productos admiten cupón y enviar un correo distinto cuando el pedido lleva descuento.

Balance: desarrollo rápido y sencillo (una transacción, un repositorio, un despliegue), pero con dependencia del calendario global de despliegue, riesgo de pisarse con otros cambios y un despliegue que arrastra todo.

Balance: más trabajo inicial (definir servicio, API, contratos, manejo de fallos), pero despliegues independientes, equipos que no se pisan y una capacidad de negocio (promociones) que nace ya aislada y podrá evolucionar sola.

• El monolito optimiza el desarrollo del cambio; los microservicios optimizan la entrega y la evolución independiente.
• En el monolito la dificultad aparece al final (coordinar el despliegue, revertir todo). En microservicios aparece al principio (decidir límites y contratos).
• El manejo de fallos, que en el monolito lo resuelve la transacción, en microservicios es una decisión explícita de diseño.

La elección no es binaria. Entre "un monolito" y "docenas de microservicios" existen paradas intermedias válidas:

• Monolito modular (visto en el apartado 2): mismo despliegue, límites internos rigurosos. Muchas organizaciones deberían aspirar a esto y quedarse aquí. Es también la base ideal para una futura extracción de servicios.
• SOA "clásica": servicios de grano más grueso que los microservicios, a menudo con un bus de integración. Todavía es común en grandes corporaciones. Comparte con los microservicios la idea de servicios, pero con más centralización (véase la lección 01-01).
• Pocos servicios grandes ("macroservicios"): dividir el sistema en dos o tres piezas por razones muy concretas (por ejemplo, separar el catálogo de alta lectura del resto) sin ir más allá. Es una estrategia pragmática que captura parte de las ventajas con una fracción del coste.

Ninguna de estas opciones es "hacer trampas". Son puntos distintos de un mismo espectro, y lo razonable es elegir el que responda a los problemas reales que se tienen.

Conviene decirlo con claridad, porque la industria a veces lo olvida: el monolito no es un error de arquitectura. Es la opción por defecto correcta para la mayoría de proyectos nuevos y para muchos sistemas maduros. Sus ventajas son reales:

• Se empieza a entregar valor en días, no en meses de infraestructura.
• Un desarrollador puede entender y ejecutar todo el sistema en su portátil.
• Las transacciones y los JOIN resuelven gratis problemas que en microservicios cuestan patrones complejos.
• Refactorizar es fácil porque el compilador o las pruebas ven todo el código a la vez; mover una responsabilidad de un módulo a otro es cambiar un import, no renegociar un contrato entre equipos.
• Operarlo es barato: un proceso, una base de datos, un log.

Empresas grandes y muy respetadas operan monolitos enormes con éxito, y otras que migraron a microservicios han vuelto parcialmente a consolidar servicios porque el coste operativo no compensaba. Los microservicios no hacen bueno un sistema; resuelven un conjunto concreto de problemas (escalado desigual, equipos que se estorban, ciclos de despliegue lentos) a cambio de otro conjunto de problemas. Si no tienes los primeros, no compres los segundos.

El caso de TechCorp que seguimos en el curso está elegido precisamente porque sí tiene esos problemas: campañas que saturan solo el catálogo, despliegues semanales con miedo, equipos que se pisan en el mismo código. Por eso su historia es una historia de migración. Pero un TechCorp de cuatro personas y mil pedidos al mes debería quedarse en su monolito, idealmente modular, y ser feliz.

• Confundir monolito con código malo. Un monolito puede estar impecablemente organizado. Si el problema es que el código es un caos, la solución es refactorizar hacia un monolito modular, no repartir el caos por la red.
• Comparar un monolito real con unos microservicios idealizados. Es fácil ganar el debate si se compara el monolito heredado lleno de deuda técnica con un diagrama limpio de servicios. Compara con la misma honestidad: los microservicios también acumulan deuda, solo que distribuida.
• Olvidar el coste inicial. La tabla comparativa muestra que los microservicios pagan por adelantado. Si el proyecto necesita entregar valor en semanas, ese coste puede ser prohibitivo.
• Pensar que las transacciones "se sustituyen" sin más. El paso de "una transacción que lo hace todo" a "varios servicios sin transacción común" es la parte más difícil de la comparación y merece la mayor atención en el diseño.
• Consejo: al evaluar un cambio funcional, haz el ejercicio del apartado 5 mentalmente: recorre los pasos en tu arquitectura actual y en la alternativa. Es la forma más rápida de detectar dónde están los costes reales.

Para cada descripción, indica si se trata de un monolito clásico, un monolito modular o microservicios, y justifica con la tabla del apartado 2.

1. Una aplicación Node.js en un único repositorio, dividida en carpetas clientes/, catalogo/, pedidos/, cada una con su propio conjunto de tablas al que las demás carpetas solo acceden a través de funciones públicas del módulo; se despliega como un único proceso.
2. Seis procesos Node.js independientes, cada uno con su base de datos, que se comunican por HTTP y RabbitMQ y se despliegan por separado.
3. Una aplicación Java desplegada como un único fichero .war en la que cualquier clase puede ejecutar consultas SQL sobre cualquier tabla.

Marta pide otra funcionalidad: lista de deseos (un cliente puede guardar productos para más adelante y recibir un correo si bajan de precio). Describe, en formato de lista de pasos como en el apartado 5, cómo se implementaría en el monolito actual de TechCorp y en la versión de microservicios. Señala en cada uno el paso más costoso.

Un compañero afirma: "Los monolitos son cosa del pasado; cualquier proyecto serio hoy debería empezar con microservicios". Escribe tres argumentos, apoyados en la tabla del apartado 3, para rebatirlo.

Ejercicio 1

1. Monolito modular. Una unidad de despliegue, pero con límites explícitos entre módulos y datos "privados" por módulo. Es exactamente el punto intermedio descrito.
2. Microservicios. Varias unidades de despliegue, base de datos por servicio, comunicación por red.
3. Monolito clásico (y probablemente con tendencia a bola de barro). Una unidad de despliegue y acceso indiscriminado a los datos.

Ejercicio 2 (una solución posible)

Monolito:

1. Migración: tabla lista_deseos (cliente_id, producto_id, precio_en_el_momento).
2. Endpoints en las rutas de clientes para añadir y listar deseos, con un JOIN a productos para mostrar nombre y precio actual.
3. Al actualizar el precio de un producto (módulo de catálogo), consultar lista_deseos y llamar a la función de notificaciones para enviar el correo, todo en el mismo proceso.
4. Pruebas de la aplicación completa; despliegue semanal. Paso más costoso: el despliegue conjunto y las pruebas lentas; el desarrollo en sí es sencillo.

Microservicios:

1. Decidir dónde vive la lista de deseos: probablemente en servicio-clientes (es una preferencia del cliente).
2. servicio-clientes añade su tabla y endpoints; para mostrar nombre y precio actual debe llamar a servicio-catalogo o guardar una copia local actualizada por eventos.
3. servicio-catalogo publica un evento producto.precio-cambiado; servicio-clientes lo consume, busca quién tenía ese producto en su lista y publica algo como deseo.bajada-precio; servicio-notificaciones lo consume y envía el correo.
4. Contratos: definir los dos eventos nuevos y sus campos.
5. Despliegues independientes de catálogo, clientes y notificaciones, en ese orden. Paso más costoso: decidir cómo obtiene clientes los datos del producto (llamada síncrona frente a copia por eventos) y diseñar la cadena de eventos; hay que pensar en fallos y duplicados.

Ejercicio 3 (argumentos posibles)

• Coste inicial: un monolito entrega valor en días con un servidor y una base de datos; los microservicios exigen contenedores, orquestación, mensajería y observabilidad antes de la primera funcionalidad. Para un proyecto nuevo, cuyo mayor riesgo es no encontrar mercado, ese coste es difícil de justificar.
• Datos y rendimiento: en un monolito, una transacción y un JOIN resuelven problemas que en microservicios requieren sagas, duplicación de datos y llamadas por red con latencia. Mientras el dominio no esté claro, esa simplicidad vale oro.
• Equipos: las ventajas de autonomía de los microservicios solo aparecen cuando hay varios equipos que se estorban. Con un único equipo pequeño no hay a quién dejar de estorbar, y sí hay muchos más servicios que operar. Además, un monolito modular ofrece límites claros sin coste de red y deja abierta la puerta a extraer servicios más adelante.

En esta lección hemos definido el monolito como una única unidad de despliegue con una base de datos compartida y llamadas internas en memoria, y hemos presentado el monolito modular como una variante disciplinada que combina la sencillez operativa del monolito con límites internos claros. La comparación dimensión a dimensión ha mostrado un patrón consistente: el monolito es barato y simple al principio y se complica al crecer, mientras que los microservicios pagan un coste inicial alto a cambio de mantener acotada la complejidad de cada pieza y permitir despliegues, escalado y equipos independientes. El recorrido del cambio "cupones de descuento" ha hecho tangible dónde aparecen las dificultades en cada caso: al final del ciclo en el monolito, al principio en los microservicios. Y hemos dejado claro que el monolito no es una arquitectura de segunda: es la opción correcta para muchos sistemas.

Con esta comparación en la mano, ya podemos abordar la pregunta que de verdad importa en la práctica: ¿cuándo conviene adoptar microservicios y cuándo no? La siguiente lección da criterios concretos, señales de alarma, prerrequisitos y una lista de comprobación para tomar esa decisión con fundamento.