Después de migrar sistemas monolíticos a microservicios en proyectos como RUNT 2.0 y SAGCOM, he aprendido que la respuesta nunca es blanco o negro.
El mito del microservicio obligatorio
En la industria existe una presión constante por adoptar microservicios. Pero un monolito bien diseñado con módulos claros puede superar a una arquitectura de microservicios mal implementada. Lo he visto ocurrir: equipos pequeños con 2-3 desarrolladores intentando mantener 15 microservicios con toda la complejidad operacional que eso conlleva.
Framework de decisión
La clave está en entender el contexto. Estos son los factores que evalúo antes de proponer una arquitectura:
- ▹ Tamaño del equipo: Con menos de 5 devs, un monolito modular suele ser más productivo. Los microservicios brillan cuando hay equipos autónomos.
- ▹ Complejidad del dominio: Si tu dominio tiene bounded contexts claros y diferentes ciclos de vida, los microservicios tienen sentido.
- ▹ Requisitos de escalabilidad: Si solo una parte de tu sistema necesita escalar (ej: procesamiento de pagos en Bancolombia), puedes extraer solo ese servicio.
- ▹ Madurez operacional: Sin CI/CD sólido, observabilidad y orquestación de contenedores, los microservicios son un dolor.
Caso real: SAGCOM en Previred
En SAGCOM 2.0 optamos por microservicios porque teníamos: un equipo de +10 desarrolladores, bounded contexts claros (evaluación médica, expedientes, sesiones, apelaciones, agenda), diferentes necesidades de escalado y un AWS maduro con ECS/Kubernetes. Cada servicio tiene su propia base de datos (SQL Server) y se comunican via REST y eventos.
Caso contrario: e-TRIB en SEDATEZ
Para el sistema tributario e-TRIB, un monolito Laravel fue la decisión correcta. Equipo de 3 personas, dominio único (recaudación), servidor único. Agregar la complejidad de microservicios hubiera sido sobre-ingeniería pura.
Mi recomendación
Empieza con un monolito modular. Diseña bien tus módulos con interfaces claras. Cuando el dolor de coordinación entre equipos o la necesidad de escalar independientemente sea real (no teórica), extrae microservicios. Esta aproximación es más segura y pragmática que diseñar microservicios desde el día uno.
