¿Cuándo realmente compensa dividir un monolito en microservicios, y cuándo es un error costoso?
Los microservicios cambian un problema difícil (un código enredado) por otro (una red enredada) — la pregunta es si tu organización es más grande que el problema que resuelve.
APRENDE HACIENDOPon a prueba tu intuición3 pasos
¿Cuándo realmente compensa dividir un monolito en microservicios, y cuándo es un error costoso?
Usa los ejemplos y la explicación de la lección para comprobar tu idea.
Reflexión personal. No se envía a ningún servicio de IA.#Es una decisión organizacional disfrazada de decisión técnica
Los equipos preguntan "¿deberíamos usar microservicios?" como si fuera una elección de framework. Casi nunca lo es. Dividir un sistema en servicios desplegables de forma independiente cambia muy poco lo que el sistema calcula — cambia quién puede modificar qué, con qué velocidad, y sin tener que pedirle permiso a nadie más. Si evalúas la división solo por sus méritos técnicos (escalabilidad, aislamiento de fallos, flexibilidad políglota) casi siempre llegarás a la respuesta equivocada, porque el costo dominante de los microservicios es organizacional y operativo, no algorítmico.
#La Ley de Conway pone el techo
La observación de Melvin Conway de 1967 sigue vigente: cualquier organización que diseña un sistema producirá un diseño cuya estructura es una copia de la estructura de comunicación de esa organización. Tres equipos que se hablan constantemente entre sí y casi nunca con un cuarto equipo producirán, con el tiempo, tres módulos fuertemente acoplados y uno aislado — sin importar lo que diga el diagrama de arquitectura el primer día. Pelear contra esto a base de mejores diagramas no funciona; el código sigue al organigrama, no a la pizarra.
La consecuencia práctica es la maniobra inversa de Conway: si quieres un sistema modular y desplegable de forma independiente, primero reorganizas los equipos en unidades modulares con responsabilidad propia, y dejas que la estructura del software alcance después a la organizacional. Por eso el vocabulario de Team Topologies —equipos alineados a un flujo de valor que poseen un contexto delimitado de punta a punta, con equipos de plataforma y de habilitación reduciendo su carga cognitiva— suele aparecer junto con la adopción de microservicios. Un límite de servicio que no corresponde a un límite de equipo suele ser un límite que se pudre, porque nadie tiene autoridad plena (ni incentivo pleno) para mantenerlo limpio.
#Cuándo la división vale la pena
La división justifica su costo cuando varias de estas condiciones se cumplen a la vez:
- Escalado independiente. Una capacidad (por ejemplo, el procesamiento de imágenes) necesita 50 veces el cómputo del resto del sistema, y acoplarla al mismo desplegable significa sobre-aprovisionar todo lo demás.
- Ritmo de despliegue independiente. El equipo de facturación despliega semanalmente bajo control de auditoría; el equipo de recomendaciones despliega diez veces al día. Forzarlos por el mismo pipeline convierte la prudencia de uno en el cuello de botella del otro.
- Escala organizacional. Pasados los ocho o doce ingenieros haciendo commits al mismo desplegable, el costo de coordinación (conflictos de merge, colas de CI compartidas, "¿quién rompió el build?") empieza a dominar sobre la velocidad de entrega de funcionalidades.
- Necesidad de aislamiento de fallos. Necesitas que una dependencia lenta o inestable (digamos, una verificación de fraude de un tercero) se degrade con elegancia en lugar de tumbar el checkout completo.
- Contextos delimitados genuinos. El Domain-Driven Design ya reveló una costura real — inventario y facturación de verdad tienen modelos de datos, vocabularios y ciclos de vida distintos— y esa costura es estable, no todavía en descubrimiento.
#Cuándo es un error costoso
La división suele ser prematura cuando un equipo pequeño (más o menos el tamaño de uno o dos equipos "de dos pizzas") adopta microservicios porque es la opción de moda o "lo que hace Netflix", sin la madurez operativa para pagar el impuesto correspondiente: CI/CD automatizado por servicio, observabilidad por servicio (trazas distribuidas, no solo métricas por host), guardias de turno por servicio, y pruebas de contrato entre servicios. Sin eso, no obtienes dominios de fallo aislados — obtienes los mismos fallos de siempre, ahora más difíciles de reproducir, repartidos por una red que tienes que instrumentar solo para poder verlos.
:::warning El monolito distribuido El peor desenlace no es "monolito" ni "microservicios" — es pagar ambos costos sin obtener ninguno de los dos beneficios, lo que se conoce como monolito distribuido. Su firma característica: los servicios se dividen por capa técnica (un "servicio DAO", un "servicio de validación") en lugar de por capacidad de negocio; varios servicios comparten una misma base de datos o esquema, así que una migración de esquema exige coordinar despliegues entre equipos; y una sola petición lógica se abre en una larga cadena de llamadas síncronas, así que un cambio en un servicio obliga a redesplegar —o al menos reprobar— varios otros en lockstep. Ahora pagas latencia de red, fallos parciales y depuración distribuida, pero sigues sin poder desplegar ningún servicio de forma independiente. Tienes todo el impuesto de los sistemas distribuidos y ninguno de los dividendos de los microservicios. :::
#Una lista de señales
| Señal | Favorece seguir monolítico (o un monolito modular) | Favorece dividir |
|---|---|---|
| Tamaño del equipo sobre el código | 1–2 equipos, todos conocen el sistema completo | 3+ equipos que casi nunca necesitan tocar el código del otro |
| Ritmo de despliegue necesario | Uniforme entre funcionalidades | Muy distinto según la capacidad (diario vs. trimestral) |
| Propiedad de los datos | Un esquema único y compartido que evoluciona junto | Contextos delimitados ya naturalmente separados |
| Perfil de escalado | Carga más o menos uniforme en todo el sistema | La carga de una capacidad es un orden de magnitud distinta |
| Madurez operativa | Todavía sin CI/CD, trazas ni guardias por servicio | Ya cuenta con pipelines automatizados, trazas distribuidas, pruebas de contrato |
| Necesidad de aislar fallos | Es aceptable que un componente lento bloquee la petición | Una dependencia lenta o inestable no puede tumbar el resto |
#La Ley de Conway, visualizada
Fíjate en que el equipo que casi no habla con los demás produce el único servicio con una interfaz genuinamente delgada y estable — eso no es casualidad, es el mecanismo en acción.
:::tip Empieza como un monolito modular Si no estás seguro de que los contextos delimitados sean reales, hazlos cumplir como módulos dentro de un solo desplegable primero: paquetes separados, sin acceso cruzado a bases de datos entre módulos, un linter que prohíba importaciones ilegales. Si los módulos se mantienen limpios durante algunos trimestres y aparecen las presiones de equipo/escalado mencionadas arriba, extraer un módulo a su propio servicio es una refactorización mecánica. Extraer de un sistema donde esos límites nunca se hicieron cumplir es una reescritura. :::
:::key Ley de Conway "Cualquier organización que diseña un sistema producirá un diseño cuya estructura es un espejo de la estructura de comunicación de esa organización." Los límites de servicio que no coinciden con límites de equipo tienden a no sobrevivir el contacto con un roadmap. :::
🧠 Check your understanding
0/3 · 0/3 answered1. Un único equipo de 7 ingenieros divide su producto en 14 microservicios para 'escalar como Netflix'. ¿Cuál es el resultado más probable?
2. ¿Qué recomienda la 'maniobra inversa de Conway'?
3. ¿Cuál es la firma más clara de un 'monolito distribuido'?