Hay una decisión de arquitectura que se toma mal una y otra vez, casi siempre en la misma dirección: partir un sistema en microservicios antes de tiempo. La verdad incómoda es que la mayoría de los equipos que adoptan microservicios no tienen el problema que los microservicios resuelven — y pagan toda su complejidad a cambio de nada. Este artículo es la guía para decidir con criterio: qué te cobra cada opción, cuándo el monolito es la respuesta correcta (casi siempre al principio) y cuáles son los disparadores reales para partir.
Qué es cada cosa, sin misticismo
Un monolito es una sola aplicación desplegable: toda la lógica vive en un código, corre como una unidad y suele hablar con una base de datos. Microservicios parten esa aplicación en muchos servicios pequeños e independientes, cada uno con su propia base de datos, que se despliegan por separado y se comunican por la red.
La diferencia clave no es el tamaño del código: es que en microservicios cambias llamadas a funciones (instantáneas, confiables, transaccionales) por llamadas de red (lentas, falibles, sin transacciones). Todo lo que sigue sale de esa única frase.
De dónde salió el hype
Microservicios se volvió moda porque Netflix, Amazon y Google los usan. El razonamiento implícito —“si lo hacen los gigantes, debe ser lo correcto”— es cargo cult programming en estado puro: copiar la forma sin entender la causa. Esos gigantes adoptaron microservicios para resolver problemas de miles de ingenieros pisándose en un mismo código y de escala planetaria. Si no tienes cientos de desarrolladores ni millones de peticiones por segundo, estás copiando la solución a un problema que no tienes.
Martin Fowler, que ayudó a popularizar el término, fue de los primeros en frenar: acuñó la idea de “Monolith First” y la regla de que hay un “tamaño mínimo” para que los microservicios valgan la pena. La industria tardó años en escucharlo.
Lo que los microservicios te cobran
Partir un sistema no es gratis. Estos son los costos que rara vez aparecen en la presentación entusiasta:
- La red no es confiable. Lo resumen las falacias de la computación distribuida: la red no es fiable, tiene latencia, ancho de banda finito y puede caerse. Cada llamada entre servicios es una oportunidad de fallo que en un monolito ni existía.
- Adiós a las transacciones. En un monolito, “cobra y descuenta inventario” es una transacción ACID: o pasan las dos cosas o ninguna. Repartido en dos servicios con dos bases de datos, eso se vuelve consistencia eventual, sagas y lógica de compensación. Acabas reimplementando a mano lo que tu base de datos te daba gratis.
- La operación se multiplica. Un desplegable se vuelve veinte. Ahora necesitas orquestación (Kubernetes), service discovery, observabilidad distribuida (un error cruza cinco servicios), versionado de APIs y CI/CD por servicio. La complejidad no desaparece: se muda de tu código a tu infraestructura.
- Depurar se vuelve arqueología. Un stack trace ya no te cuenta toda la historia; tienes que correlacionar trazas entre servicios para entender qué pasó. Lo que en un monolito era poner un breakpoint, ahora es un proyecto.
- Latencia y testing. Lo que era una llamada en memoria ahora viaja por la red, y probar un flujo completo exige levantar (o simular) media docena de servicios.
Ninguno de estos costos es un argumento para no usar microservicios nunca. Son el precio que pagas — y que solo vale la pena si compras algo que de verdad necesitas.
El monolito distribuido: lo peor de ambos mundos
El fracaso más común no es “monolito” ni “microservicios bien hechos”: es el monolito distribuido. Pasa cuando partes el sistema en servicios pero los dejas tan acoplados que tienen que desplegarse juntos y se llaman en cadena de forma síncrona. Resultado: pagas toda la complejidad de lo distribuido y no obtienes ninguna de sus ventajas.
Si tus “microservicios” se despliegan siempre juntos, comparten base de datos o una caída en uno tumba al resto, no tienes microservicios: tienes un monolito que además se comunica por la red. La peor combinación posible.
Cuándo el monolito es la respuesta correcta
Casi siempre, sobre todo al principio. Un monolito (bien hecho) te da ventajas enormes que se subestiman:
- Simplicidad de operación. Un desplegable, un log, una base de datos. Un junior puede correr todo el sistema en su laptop.
- Transacciones de verdad. Consistencia fuerte sin sagas ni malabares.
- Refactor barato. Mover un límite entre módulos es un rename en tu IDE, no una negociación entre dos equipos y dos despliegues.
- Velocidad. Sin saltos de red, sin serialización, sin gateways.
DHH (de 37signals/Basecamp) lo defiende como el “majestic monolith”: empresas con millones de usuarios operan felices sobre un monolito bien estructurado. El monolito no es una etapa vergonzosa que superas; para la mayoría de los productos es el destino correcto.
El término medio: el monolito modular
La falsa dicotomía es “espagueti monolítico vs microservicios”. Hay una tercera opción, y suele ser la mejor: el monolito modular. Un solo desplegable, pero internamente dividido en módulos con límites claros — cada uno con su responsabilidad, su API interna y sin meter mano en las tablas del otro.
Esto te da el 90% del beneficio de los microservicios (código organizado, equipos que no se pisan, límites explícitos) sin pagar el impuesto de la red. Y lo mejor: si algún día de verdad necesitas extraer un módulo a su propio servicio, los límites ya están dibujados. Es la Ley de Gall aplicada: un sistema complejo que funciona evolucionó de uno simple que funcionaba. Empiezas simple y dejas que la realidad —no la moda— justifique cada corte.
Cuándo SÍ tiene sentido partir
Hay disparadores legítimos. Fíjate que casi todos son problemas de organización y escala, no de “código limpio”:
- Autonomía de equipos a escala. Si tienes muchos equipos y se bloquean entre sí para desplegar, partir por equipo tiene sentido. Es la Ley de Conway usada a favor: alineas servicios con equipos para que cada uno avance solo. (Si tienes un equipo, este punto no aplica — y probablemente ninguno.)
- Escalado independiente. Un componente recibe 100× el tráfico del resto (p. ej. el de búsqueda o el de pagos en un pico). Sacarlo a su propio servicio te deja escalar solo eso en vez de clonar todo el monolito.
- Aislamiento de fallos. Necesitas que si se cae el módulo de reportes, el de cobros siga vivo. La frontera de proceso da ese aislamiento.
- Heterogeneidad técnica real. Un componente necesita otro lenguaje o runtime (p. ej. un servicio de ML en Python dentro de un sistema en TypeScript).
- Aislamiento de datos / regulación. Cumplimiento que exige separar ciertos datos en su propio dominio.
Si reconoces uno de estos con un ejemplo concreto —no “por si crecemos”—, partir empieza a tener sentido. Si tu justificación es “es más profesional” o “así escala mejor” sin un cuello de botella medido, es optimización prematura con esteroides.
Si tienes que partir, hazlo bien
Extraer microservicios no es un evento de “big bang” donde reescribes todo. Es evolutivo, un servicio a la vez, con el patrón del estrangulador (strangler fig): rodeas el monolito, extraes una pieza por una costura clara, la estabilizas, y solo entonces consideras la siguiente.
Las costuras correctas son de dominio, no técnicas. Partir por “capas” (un servicio para la base de datos, otro para la lógica, otro para la UI) es el error clásico: acoplas todo lo que debería ir junto. Partir por contextos acotados —en el sentido del Domain-Driven Design— es lo que hace que cada servicio sea de verdad independiente. Por eso el monolito modular es tan buen punto de partida: si ya tienes los módulos bien trazados, las costuras para extraer ya existen.
La decisión, en un árbol
Cuando alguien proponga microservicios, recórrelo de arriba a abajo. Si en cualquier punto la respuesta es “no”, la respuesta a “¿microservicios?” es “todavía no”:
En una frase
Microservicios son una herramienta para un problema organizacional y de escala específico — no un sello de calidad ni una meta. Si no puedes nombrar el cuello de botella concreto que resuelven en tu caso, el monolito modular casi siempre gana: más simple, más rápido de cambiar, y listo para partirse el día (si llega) que la realidad lo exija. La arquitectura más profesional no es la más sofisticada; es la más simple que resuelve tu problema de hoy.
¿Tienes que decidir esto para un proyecto y no quieres equivocarte en la dirección cara? Es justo el tipo de decisión que ayudamos a tomar cuando construimos software a medida. Si quieres una segunda opinión con criterio, hablémoslo.
Referencias
- Martin Fowler — MonolithFirst y Microservices (martinfowler.com).
- Sam Newman — Building Microservices y Monolith to Microservices (O’Reilly).
- David Heinemeier Hansson (37signals) — The Majestic Monolith.
- Melvin Conway — How Do Committees Invent? (1968) — ley de Conway.
- John Gall — Systemantics — ley de Gall (“worse is better”).
- Eric Evans — Domain-Driven Design — contextos acotados.
- Falacias de la computación distribuida (Peter Deutsch et al., Sun Microsystems).