La conversación sobre microservicios maduró. Ya no es "monolito o microservicios" como decisión binaria, sino una curva: empezar con un monolito bien diseñado y migrar a microservicios solo cuando el sistema lo demande.
El monolito bien diseñado
Un monolito modular, con límites claros entre dominios internos, sin dependencias circulares, con tests automatizados y despliegues frecuentes, escala mucho más de lo que la industria cree. Empresas con cientos de miles de usuarios siguen operando con monolitos así.
Cuándo aparecen las razones reales para migrar
- Diferentes partes del sistema necesitan escalar a ritmos distintos.
- Equipos distintos necesitan desplegar de forma independiente.
- Una parte del sistema requiere un stack tecnológico incompatible con el resto.
Estas tres condiciones son las únicas que justifican el costo de operación de microservicios. Cualquier otra razón suele ser "se ve más moderno" o "lo recomienda un consultor".
El costo real de microservicios
- Observabilidad distribuida obligatoria.
- Versionado de APIs entre servicios.
- Estrategia de deployment y rollback por servicio.
- Manejo de consistencia eventual.
- Latencia de red entre servicios.
Un equipo pequeño que pasa a microservios termina dedicando más tiempo a la operación que al producto. Solo vale la pena cuando el negocio lo sostiene.
El camino recomendado
1. Empezar con un monolito modular bien testeado.
2. Cuando duela un problema específico y bien identificado, extraer ese servicio.
3. Mantener la base de datos central mientras sea posible. Microservicios con base de datos compartida es el peor de los mundos.
4. Migrar datos al servicio nuevo solo cuando el corte sea viable.
Cierre
La moda de microservicios pasó. Lo que queda es criterio: monolito por defecto, extracción quirúrgica cuando la operación lo exige.
En CodeHub diseñamos la arquitectura de cada producto nuevo como monolito modular y ayudamos a empresas a decidir cuándo y cómo extraer servicios específicos sin romper la operación.