De monolito a microservicios: lo que nadie te cuenta antes de empezar

He participado en tres migraciones de monolito a microservicios a lo largo de mi carrera. Una salió bien. Otra salió regular. La tercera fue un desastre que acabamos revirtiendo parcialmente. Con esa perspectiva, estas son las cosas que nadie te cuenta antes de empezar — o que te cuentan y decides ignorar porque "esta vez será diferente".

La primera verdad: tu monolito probablemente no es tan malo

Hay una narrativa en la industria que presenta los monolitos como algo que superar. La realidad es que un monolito bien estructurado, con módulos claros y buenas prácticas, puede escalar mucho más de lo que la gente cree.

Si tu aplicación Spring Boot tiene 50.000 líneas, la despliegan 3-4 personas y el rendimiento es aceptable, no necesitas microservicios. Lo que probablemente necesitas es mejor modularización interna.

La pregunta no es "¿deberíamos migrar a microservicios?" sino "¿qué problema concreto tenemos que no podemos resolver con nuestro monolito?". Si la respuesta es vaga — "escalar mejor", "ser más ágiles" — probablemente no estás listo.

Lo que realmente cambia (y duele)

El despliegue se multiplica

Con un monolito, tienes un pipeline de CI/CD. Con 12 microservicios tienes 12 pipelines, 12 Dockerfiles, 12 configuraciones de Kubernetes, 12 monitorizaciones. Y cada uno puede fallar de forma independiente.

En el proyecto que falló, pasamos de hacer deploy en 15 minutos a tener un proceso de 2 horas que requería coordinar el orden de despliegue entre servicios. El equipo no estaba preparado para ese salto operativo.

Los datos dejan de ser simples

En un monolito, necesitas datos de dos entidades y haces un JOIN. En microservicios, esas entidades viven en bases de datos separadas. Ahora necesitas una llamada HTTP, manejar la latencia, gestionar qué pasa cuando un servicio no responde, y aceptar consistencia eventual.

Las transacciones distribuidas son la pesadilla que nadie quiere implementar. Sagas, eventos compensatorios, idempotencia — todo esto es complejidad real que antes no existía.

Los bugs se vuelven distribuidos

Debuggear un bug en un monolito es seguir un stack trace. Debuggear un bug en microservicios es correlacionar logs de 5 servicios diferentes, entender el orden temporal de los eventos y rezar para que alguien configurara tracing distribuido correctamente.

Sin observabilidad seria (OpenTelemetry, Jaeger o similar), estás ciego.

Cuándo sí tiene sentido migrar

Después de los golpes, hay escenarios donde los microservicios son la respuesta correcta:

Equipos grandes (8+ devs) que se pisan constantemente en el mismo repositorio
Partes del sistema con requisitos de escalado muy diferentes — un servicio que procesa millones de eventos y otro que sirve un dashboard
Ciclos de release independientes — necesitas desplegar el módulo de pagos sin tocar el de inventario
Stack tecnológico diverso — parte del equipo quiere Python para ML y el resto trabaja en Java

Si no tienes al menos dos de estos puntos, piénsalo dos veces.

El camino intermedio que nadie menciona

Antes de saltar a microservicios, explora estas opciones:

Modular monolith: mismo deployable, pero con módulos internos bien aislados. Spring Modulith facilita esto en el ecosistema Java. Obtienes buena separación de contextos sin la complejidad distribuida.

Extraer solo lo necesario: no migres todo. Identifica el componente que realmente necesita independencia y extráelo. Un monolito con 2-3 servicios satélite es una arquitectura perfectamente válida.

Mi regla de oro

Si tu equipo no tiene experiencia operando infraestructura distribuida — si no sabéis de Kubernetes, observabilidad, mensajería asíncrona — no empecéis por microservicios. Empezad por aprender esas herramientas con un monolito bien desplegado. La arquitectura distribuida amplifica tanto las buenas como las malas prácticas.

El mejor consejo que he recibido sobre esto: "Gánate el derecho a tener microservicios demostrando que puedes operar un monolito bien."

No hay nada de malo en tener un monolito en producción. Lo que sí está mal es migrar a microservicios porque es tendencia, sin tener los problemas que justifican esa complejidad. El software existe para resolver problemas de negocio, no para satisfacer nuestra curiosidad técnica.