Los microservicios se han convertido en sinónimo de “arquitectura moderna”, y esa asociación es peligrosa. Descomponer un sistema en servicios pequeños y desacoplados no es un objetivo en sí mismo: es una decisión de arquitectura con costes reales que debe justificarse.
Qué son realmente
Una arquitectura de microservicios organiza el sistema como un conjunto de servicios pequeños, independientes y desplegables por separado, cada uno responsable de una parte del dominio y comunicados mediante APIs y eventos. La ganancia principal no es la tecnología, sino la independencia de los equipos y la capacidad de evolucionar partes del sistema sin tocar el todo.
Cuándo compensan
- Escalado diferenciado: cuando distintas partes del sistema tienen cargas muy distintas y conviene escalarlas por separado.
- Equipo grande y maduro: cuando hay varios equipos que necesitan desplegar de forma autónoma, sin bloquearse entre sí.
- Límites de dominio claros: cuando el negocio tiene fronteras naturales bien definidas (por ejemplo, catálogo, pedidos, facturación).
- Ciclo de vida distinto: cuando algunas partes cambian mucho más rápido que otras.
Los microservicios pagan su coste cuando resuelven un problema de acoplamiento entre equipos. Si el problema es otro, probablemente un monolito bien estructurado sea mejor opción.
Los costes que se subestiman
Descomponer el sistema introduce complejidad operativa: latencia en las comunicaciones, consistencia distribuida, despliegues coordinados, observabilidad, pruebas de extremo a extremo. Esa complejidad es un impuesto permanente que hay que pagar desde el primer día, no solo cuando el sistema crece.
Errores frecuentes
- Nano-servicios: descomponer demasiado, generando una red de servicios diminutos difíciles de rastrear.
- Descomponer por capas: separar en “servicio de datos”, “servicio de lógica”, etc., en vez de por dominio de negocio.
- Ignorar los datos: sin una estrategia de datos clara (bases por servicio, sincronización), la integración se vuelve frágil.
- Empezar por la tecnología: elegir contenedores o un orquestador antes de haber definido los límites del dominio.
Un monolito modular bien hecho puede evolucionar a microservicios con mucha menos fricción que al revés.
Un camino prudente
La mayoría de organizaciones se benefician más de un monolito modular con límites de dominio claros que de una migración prematura a microservicios. Esa estructura deja las puertas abiertas para desacoplar después, cuando el negocio y el equipo lo justifiquen.
El punto de partida que trabajo con mis clientes es siempre el mismo: definir bien los límites del dominio. Cuando esos límites son correctos, la decisión entre monolito y microservicios deja de ser una moda y se convierte en una elección con criterio.