Estilos de despliegue
Monolito, modulith, microservicios, event-driven, SOA, space-based. Tradeoffs comparados.
Cómo se entrega y escala el sistema en producción. Estos no son patrones de código, sino estilos arquitectónicos que afectan al equipo, al deployment, al costo operativo y, sobre todo, a cuánto tarda un cambio en llegar a producción.
#El problema
Elegir mal el estilo de despliegue es caro de revertir. Un monolito que crece sin fronteras se vuelve imposible de escalar de forma quirúrgica: o escalás todo, o no escalás nada. Pero romperlo en treinta microservicios sin madurez operativa te da lo peor de los dos mundos: la complejidad de un sistema distribuido y los acoplamientos del monolito que dejaste atrás.
#La solución
No hay estilo "correcto", hay un estilo adecuado a tu equipo, dominio y presupuesto operativo. Conocer las opciones —monolito, modulith, microservicios, event-driven, space-based, SOA— y entender sus tradeoffs reales te permite elegir con la cabeza fría, no por moda. La mayoría de los proyectos están mejor con un buen modulith que con malos microservicios.
#La pregunta real
No es "¿monolito o microservicios?". Es:
- ¿Cuántos equipos independientes van a tocar este sistema?
- ¿Qué partes necesitan escalar de forma distinta?
- ¿Tu equipo tiene la madurez operativa para correr 30 servicios?
- ¿Cuánto te cuesta una hora de downtime?
Las respuestas mandan; las modas no.
#En este capítulo
- Monolito — un solo despliegue, tan vigente como siempre.
- Modulith — monolito con fronteras internas explícitas (la opción correcta el 80% del tiempo).
- Microservicios — autonomía por servicio, complejidad por sistema.
- Microservicios distribuidos vs monolito distribuido — la diferencia que casi nadie enseña.
- SOA — el abuelo de los microservicios.
- Event-driven — comunicación asincrónica como columna vertebral.
- Space-based — escalado horizontal sin base de datos como cuello de botella.
- Microkernel / Pipeline / P2P — estilos menos populares pero útiles en su nicho.
#Cómo leer este capítulo
Cada página describe fortalezas, debilidades, costo operativo y señales de que lo elegiste mal. Hay también una página de comparación lado a lado para facilitar la decisión.
Spoiler: para la mayoría de los proyectos, un buen modulith vence a un mal conjunto de microservicios.
#Lecturas relacionadas
- ¿Cómo organizar el código dentro del sistema? Arquitectura de aplicación.
- ¿Cómo coordinar transacciones entre servicios? Mirá Saga y Outbox.
- Microservicios — Conjunto de servicios pequeños, autónomos, desplegables independientemente, comunicados por red.
- Monolito — Toda la aplicación en un único proceso desplegable.
- Event-Driven Architecture — Componentes desacoplados se comunican publicando y reaccionando a eventos, no llamándose directamente.
- Microservicios — Múltiples servicios autónomos, cada uno con su propio deploy y su propia BD.
- Modulith (Modular Monolith) — Un único deploy, pero módulos internos con fronteras estrictas y comunicación explícita.
- SOA — Servicios reutilizables en una empresa, típicamente compartiendo un bus de servicios (ESB).
- Comparativa: Monolito vs Microservicios vs Modulith — Tabla comparativa de los tres estilos arquitectónicos principales.
- Space-Based Architecture — Replica datos y procesamiento en una grilla in-memory para escalar elásticamente y eliminar el cuello de botella de la BD.
- Microkernel (Plugin) — Núcleo mínimo que ofrece servicios base, extendido por plugins.
- Pipes & Filters (arquitectónico) — Procesamiento en etapas conectadas por pipes — versión a nivel de sistema del patrón Pipeline.
- Peer-to-Peer — Cada nodo es a la vez cliente y servidor; no hay un servidor central.