Cuándo un monolito es la respuesta correcta

La pregunta que hay detrás del capítulo

Todos los estilos de este capítulo se despliegan como una sola unidad. El Capítulo 6 lleva las mismas preguntas a través de una red, donde cada llamada puede fallar, ser lenta o llegar dos veces. Antes de cruzar esa línea, merece la pena preguntarse directamente: ¿cuándo es un monolito la respuesta correcta? Durante buena parte de la década de 2010, la respuesta por defecto del sector fue "rara vez", y muchos equipos dividieron sistemas jóvenes en microservicios porque grandes empresas famosas lo habían hecho. Una década de experiencia ha producido una visión más equilibrada, y esta sección la expone.

La palabra monolito requiere cuidado. Como explicó la Sección 5.1, describe el despliegue (una unidad que se compila, se prueba y se lanza en conjunto), no la calidad interna. Un monolito puede ser un sistema modular bien estructurado o una gran bola de barro, y lo mismo vale para un conjunto de servicios. Muchos de los problemas que se achacan a los monolitos son en realidad problemas de mala modularidad, y dividir en servicios un sistema mal modularizado produce una gran bola de barro distribuida, que es peor.

MonolithFirst y la prima de los microservicios

En mayo de 2015, Martin Fowler describió la prima de los microservicios (microservice premium): los microservicios traen costos reales propios (despliegue automatizado de muchas unidades, monitorización, gestión de fallos parciales, consistencia eventual, API versionadas entre equipos), y esos costos frenan a un equipo a menos que el sistema sea lo bastante complejo como para que los microservicios los compensen. Su consejo era partir por defecto de un único monolito bien modularizado y pasar a microservicios solo cuando la complejidad lo exija.

Un mes después, en un artículo titulado MonolithFirst (junio de 2015), añadió dos observaciones de los proyectos que había visto: casi todos los sistemas de microservicios exitosos habían empezado como un monolito que creció demasiado y luego se dividió, y casi todos los sistemas construidos como microservicios desde cero habían acabado en serios problemas. Una razón es que es difícil encontrar buenos límites entre servicios antes de entender el dominio, y un límite equivocado entre servicios es mucho más caro de mover que un límite equivocado entre módulos. Describió varias vías: construir un monolito e ir desgajando servicios de sus bordes más adelante; construir un monolito deliberadamente desechable; o empezar con unos pocos servicios de grano grueso y dividirlos más cuando los límites se asienten.

El monolito majestuoso y la postura contraria

En febrero de 2016, David Heinemeier Hansson, creador de Ruby on Rails, publicó "The Majestic Monolith" en el blog Signal v. Noise. Describió Basecamp, construido entonces por un equipo de una docena de programadores, como una aplicación integrada que servía a clientes web, móviles, de escritorio y de correo electrónico, y sostuvo que los equipos pequeños deberían apostar por un monolito bien hecho en lugar de copiar la arquitectura de organizaciones con miles de ingenieros. Su frase clave fue ¡No distribuyas tu computación!, salvo que de verdad tengas que hacerlo.

No todos los profesionales están de acuerdo. También en junio de 2015, Stefan Tilkov sostuvo en el sitio de Fowler, en "Don't start with a monolith", que dividir un monolito más adelante suele ser más difícil de lo esperado, porque sus partes acaban fuertemente acopladas a través de bibliotecas compartidas, objetos de dominio y la base de datos. Si el sistema es claramente lo bastante grande como para justificar partes separadas y el dominio se entiende bien, recomendaba diseñar subsistemas separados desde el principio. Las dos posturas están menos alejadas de lo que parece: ambas dicen que lo difícil son los límites, y un monolito cuyos módulos se hacen cumplir desde el primer día (Sección 5.3) responde a la mayor parte de la inquietud de Tilkov.

Los casos reales apuntan en ambas direcciones, pero comparten una lección. Segment describió en 2018 cómo había consolidado más de 140 servicios pequeños de nuevo en un único servicio después de que la sobrecarga operativa y unas bibliotecas compartidas cada vez más divergentes frenaran la entrega; Amazon Prime Video pasó en 2023 una carga de trabajo de monitorización de componentes serverless distribuidos a un único proceso (consulta la Sección 1.3). Del mismo modo, las organizaciones con cientos de equipos, como los casos a gran escala de la Sección 6.3, obtienen una independencia real de los servicios. La lección es el encaje: el estilo de despliegue debe corresponder a la organización, a la madurez del dominio y a las cualidades que se exigen.

Cuándo un monolito es la respuesta correcta

Un equipo pequeño. Con uno o unos pocos equipos, el costo de comunicación que eliminan los microservicios es bajo, mientras que su costo operativo es el mismo que para una organización grande. Un monolito permite que todos entiendan y cambien el sistema completo.

Un dominio incierto o un producto en fase temprana. Cuando aún estás descubriendo qué es el producto, los límites se moverán. Mover un límite entre módulos es una refactorización; moverlo entre servicios es una migración con datos, API y despliegues.

Necesidades de consistencia fuerte. Una única transacción de base de datos que abarca pedidos, pagos y existencias es sencilla y correcta en un monolito. Entre servicios necesita sagas, bandejas de salida y compensaciones (Sección 6.7).

Capacidad de operaciones limitada. Cada servicio necesita su propio pipeline, su monitorización, sus alertas, sus reglas de escalado y sus conocimientos para las guardias. Un equipo sin una plataforma para todo esto dedicará su tiempo a la fontanería.

Interacciones sensibles al rendimiento. Las llamadas dentro del proceso tardan de nanosegundos a microsegundos; las llamadas de red tardan milisegundos y pueden fallar. Las interacciones muy frecuentes entre partes del dominio son mucho más baratas dentro de un mismo proceso.

En todos estos casos, la forma recomendada es un monolito modular, no uno sin estructura. Mantiene abierta la opción de extraer servicios, como explica la Sección 5.3.

Escalar un monolito

Una creencia extendida es que los monolitos no pueden escalar. Escalan más de lo que la mayoría de los sistemas llegan a necesitar, usando el eje X del cubo de escalado descrito por Martin Abbott y Michael Fisher (ejecutar muchas copias idénticas) junto con unas pocas tácticas estándar. El Capítulo 9 trata cada una en profundidad (Sección 9.1).

Réplicas horizontales detrás de un balanceador de carga. Ejecuta muchas copias idénticas de la aplicación y reparte las solicitudes entre ellas. Esto solo funciona si la aplicación es sin estado (stateless): las sesiones, los archivos subidos y las cachés deben estar en almacenes compartidos, para que cualquier réplica pueda atender cualquier solicitud (Sección 9.2). También aporta redundancia: que falle una réplica ya no detiene el servicio.

Réplicas de lectura. La mayoría de los sistemas leen mucho más de lo que escriben. Las réplicas de lectura de la base de datos copian los cambios de la principal y atienden lecturas como el historial de pedidos y los informes, a costa del retardo de replicación (replication lag): una réplica puede ir una fracción de segundo por detrás (Sección 7.4).

Caché. Las cartas, las páginas de producto y la configuración cambian rara vez y se leen constantemente; guardarlas en caché en memoria o en una caché compartida elimina la mayor parte de la carga de la base de datos (Sección 7.6). Los recursos estáticos van a una CDN.

Procesos en segundo plano. El trabajo lento o a ráfagas (correos electrónicos, facturas en PDF, importaciones, liquidaciones) va a una cola y lo procesan procesos en segundo plano (workers). Los workers suelen ejecutar el mismo código base con un comando de arranque distinto, así que el sistema sigue siendo un único código base, pero los roles web y worker escalan por separado (Sección 9.3).

Máquinas más grandes y particionamiento. El escalado vertical de la base de datos suele ser el siguiente paso más sencillo. En sistemas muy grandes, los datos pueden particionarse por cliente (tenant) o por región, con una copia completa del monolito por partición (el eje Z del cubo de escalado). Stack Overflow es un ejemplo conocido de hasta dónde puede llegar un diseño mayoritariamente monolítico: según el informe de sus propios ingenieros, un día de febrero de 2016 sus balanceadores de carga gestionaron unos 209 millones de solicitudes HTTP, con la aplicación principal de Q&A (una aplicación multicliente para todos sus sitios de Q&A) funcionando en nueve servidores web principales, y cuatro máquinas SQL Server atendiendo a toda la red.

Señales de que ha llegado el momento de dividir

Dividir debe ser una respuesta a las pruebas, no a las modas. Las señales de que una única unidad de despliegue se ha convertido en la restricción son sobre todo organizativas y operativas:

Contención entre equipos. Varios equipos modifican el mismo código y se esperan unos a otros; los conflictos de fusión, las reuniones de coordinación y las compilaciones rotas por otros equipos aumentan a medida que crece la organización. Si los módulos ya están bien delimitados y la contención persiste, quizá lo que falte sea la independencia de despliegue.

Colas de despliegue. Los lanzamientos se agrupan en trenes porque cada cambio exige volver a probar todo el sistema; una pequeña corrección espera días detrás de trabajo no relacionado; el cambio fallido de un equipo bloquea el lanzamiento de todos.

Necesidades de escalado o de disponibilidad muy distintas. Un módulo (por ejemplo, el seguimiento de repartidores en tiempo real) necesita en el pico cincuenta veces la capacidad del resto, o debe seguir funcionando cuando todo lo demás está caído. Escalar todo el monolito para las necesidades de un módulo resulta caro.

Distinto alcance de seguridad o de cumplimiento. Los datos de tarjetas o los historiales médicos pueden justificar una unidad separada y estrictamente controlada para mantener el resto del sistema fuera del alcance de las auditorías.

Distintas necesidades tecnológicas. Por ejemplo, un modelo de machine learning que es mejor servir desde Python dentro de un monolito en Java.

Algunas razones no son buenas razones por sí solas: "los monolitos son legado", el deseo de usar una tecnología nueva o un código lento (que es un problema de diseño que dividir no arreglará y que puede empeorar al añadir llamadas de red).

Cómo dividir cuando llegue el momento

Divide de forma incremental, un módulo cada vez, empezando por el módulo que tenga a la vez el límite más claro y la razón más fuerte para salir. Modulariza primero si el código todavía no es modular: extraer un servicio de una maraña arrastra la maraña consigo. Después, extrae siguiendo los contextos delimitados (Sección 5.7): pon una API de red delante de la API existente del módulo, mueve sus datos a su propia base de datos, sustituye los eventos dentro del proceso por un intermediario de mensajes (message broker) y sustituye cualquier transacción compartida por sagas explícitas. Dirige el tráfico al nuevo servicio de forma gradual y mantén el camino antiguo hasta que el nuevo haya demostrado su valor.

Este es el enfoque strangler fig (higuera estranguladora) y sus variantes, que se tratan en la Sección 11.6. El destino a menudo no es "todo microservicios", sino un monolito con unos pocos servicios extraídos allí donde las pruebas lo exigieron; la arquitectura basada en servicios de la Sección 6.2 es un estado final habitual y pragmático.

Las valoraciones resumen los juicios hechos en cada sección y suponen implementaciones típicas. El diseño guiado por el dominio no aparece como columna porque es un método para encontrar límites, que cualquiera de estos estilos puede usar. Los sistemas reales combinan estilos: un monolito modular cuyos módulos son hexagonales por dentro, con un proceso de importación de tuberías y filtros y un microkernel para las reglas fiscales, es totalmente normal.