"Queremos hacerlo con microservicios" es una de las frases que más escuchamos al iniciar un proyecto. Los microservicios están de moda y tienen beneficios reales, pero también un costo que rara vez se menciona en las conferencias. En esta guía resumimos cómo tomamos esta decisión en los sistemas que diseñamos, como la plataforma de ventas e inventario SERVITEC.
Qué es cada cosa, sin rodeos
Un monolito es una aplicación que se compila y se despliega como una sola unidad. Puede (y debe) estar organizada por capas y módulos, pero todo corre en el mismo proceso y normalmente comparte una base de datos.
Una arquitectura de microservicios divide el sistema en servicios pequeños e independientes, cada uno con su propia base de datos, que se comunican por la red mediante APIs REST, gRPC o mensajería. Cada servicio se puede desplegar, escalar y actualizar por separado.
Lo que ganas con microservicios
- Despliegues independientes: el equipo de facturación puede publicar cambios sin esperar al de inventario.
- Escalado selectivo: si solo el módulo de reportes recibe mucha carga, escalas ese servicio y no todo el sistema.
- Aislamiento de fallos: un error en un servicio no tumba necesariamente a los demás.
- Libertad tecnológica: cada servicio puede usar la herramienta más adecuada.
Lo que pagas (y casi nadie cuenta)
- Complejidad operativa: más despliegues, más contenedores, más monitoreo, más configuración de red y de seguridad.
- Consistencia de datos: una venta que descuenta inventario ya no es una simple transacción de base de datos; hay que coordinar servicios con patrones como Saga u Outbox.
- Depuración más difícil: seguir una petición que pasa por cinco servicios exige trazabilidad distribuida y registros centralizados.
- Latencia: lo que antes era una llamada a un método ahora viaja por la red.
- Equipo: se necesita experiencia en DevOps, CI/CD y observabilidad desde el primer día.
Señales de que te conviene empezar con un monolito
- El equipo tiene menos de 8 o 10 desarrolladores.
- El dominio del negocio todavía está cambiando y no tienes claros los límites entre módulos.
- Necesitas salir al mercado rápido para validar la idea.
- No cuentas con infraestructura de contenedores ni pipeline de despliegue automatizado.
Señales de que ya necesitas microservicios
- Varios equipos se bloquean entre sí para publicar cambios.
- Partes concretas del sistema tienen cargas muy distintas y escalar todo junto sale caro.
- Los límites del dominio están claros y estables (por ejemplo: ventas, inventario, facturación, usuarios).
- Ya tienes CI/CD, monitoreo y registros centralizados funcionando.
El punto medio: monolito modular
Nuestra recomendación para la mayoría de empresas es empezar con un monolito modular: una sola aplicación, por ejemplo en .NET, organizada en módulos con fronteras estrictas. Cada módulo expone una interfaz pública, no accede directamente a las tablas de otro módulo y tiene sus propias pruebas. Así obtienes casi toda la mantenibilidad de los microservicios sin su costo operativo.
Cuando un módulo realmente necesite independencia, extraerlo como microservicio es mucho más sencillo porque sus límites ya están definidos. Este enfoque evita el peor de los escenarios: un "monolito distribuido", con todos los problemas de los microservicios y ninguna de sus ventajas.
Preguntas para tomar la decisión
- ¿Cuántas personas van a trabajar en el sistema en los próximos dos años?
- ¿Qué parte del sistema cambia más seguido y cuál necesita escalar?
- ¿Tenemos automatizado el despliegue y el monitoreo?
- ¿Qué pasa si una transacción queda a medias entre dos servicios?
Si las respuestas no son claras, empieza simple y deja la puerta abierta. La arquitectura correcta es la que tu equipo puede operar bien hoy y hacer crecer mañana.