La era del «arrepentimiento por los microservicios»: por qué los equipos vuelven en silencio a los monolitos
Por qué startups y equipos de ingeniería vuelven a los monolitos modulares tras sufrir los costos ocultos de unos microservicios prematuros.
Durante un tiempo, los microservicios parecían el siguiente paso obvio para cualquier producto de software serio.
En cuanto una startup empezaba a crecer, la conversación sobre arquitectura acababa girando hacia dividir la aplicación en servicios más pequeños. La autenticación pasaba a ser su propio servicio. Los pagos se separaban. Las notificaciones se iban a otro sitio. Al poco tiempo, un producto que había empezado como una aplicación relativamente sencilla podía terminar con una cantidad sorprendente de servicios funcionando detrás.
Y, sinceramente, había buenas razones para hacerlo.
Los microservicios resuelven problemas reales. Permiten que los equipos desplieguen partes de un sistema de forma independiente, que escalen cargas concretas sin escalar todo lo demás y que los equipos de ingeniería grandes tengan más autonomía sobre distintas partes de un producto.
Para empresas que operan a gran escala, esa separación puede ser utilísima.
El problema empieza cuando la arquitectura llega antes que el problema.
Una startup de cinco personas con unos pocos miles de usuarios no tiene las mismas necesidades de arquitectura que una empresa con cientos de ingenieros y millones de peticiones al día. Aun así, es sorprendentemente fácil construir el producto pequeño como si ese futuro ya hubiera llegado.
Ahí es donde empieza el arrepentimiento.
Los microservicios no son el problema
Conviene dejar algo claro: esto no es un argumento en contra de los microservicios.
No son malos. En la situación adecuada, son tremendamente útiles.
El problema es adoptarlos solo porque parecen la forma «correcta» de construir una aplicación moderna, y no porque el producto de verdad los necesite.
Imagina una aplicación pequeña con autenticación, pagos, perfiles de usuario y notificaciones.
Podrías convertir cada una de esas piezas en su propio servicio. En un diagrama de arquitectura, eso puede verse limpio y bien organizado.
Pero ahora cada servicio necesita un proceso de despliegue, monitorización, logs, configuración, autenticación, gestión de errores y documentación.
Algo que podría haber sido una llamada a una función dentro de la misma aplicación ahora es una petición de red.
Y las peticiones de red pueden fallar.
Un servicio puede agotar el tiempo de espera. Una base de datos puede quedarse no disponible un rato. Una petición puede reintentarse. Un servicio puede desplegar un cambio antes de que otro esté preparado para recibirlo. De repente, estás lidiando con problemas de sistemas distribuidos que sencillamente no existían cuando todo vivía dentro de una sola aplicación.
El producto no tiene por qué haberse vuelto más complicado.
La arquitectura sí.
El costo oculto de ser «escalable»
Cuando se habla de escalabilidad, normalmente se habla de tráfico.
¿Puede el sistema soportar diez veces más usuarios? ¿Puede procesar más peticiones? ¿Se puede escalar una parte concreta de la aplicación de forma independiente?
Son preguntas importantes, pero hay otro tipo de escalabilidad que es fácil pasar por alto: lo bien que el propio equipo puede entender y cambiar el sistema.
Un sistema que aguanta millones de peticiones pero que tardas tres días en entender antes de hacer un cambio pequeño no es precisamente cómodo para trabajar.
Esa es una de las razones por las que el monolito modular vuelve a resultar atractivo.
En lugar de dividirlo todo de inmediato en servicios independientes, un equipo puede mantener una sola aplicación con límites claros dentro de ella. Autenticación, facturación, usuarios, notificaciones y otros dominios pueden tener sus propios módulos y responsabilidades sin necesitar un servicio y una infraestructura aparte para cada uno.
Consigues estructura sin pagar de entrada todo el costo operativo de los sistemas distribuidos.
Y si uno de esos módulos llega a crecer lo suficiente como para justificar convertirse en un servicio aparte, puedes extraerlo más adelante.
Esa flexibilidad importa.
Diseña capturas listas para la tienda en minutos: gratis y sin marca de agua.
Empezar con Launch Shots es gratis. Todas las plantillas (más de 110), más de 220 marcos de dispositivo y mockups 3D, traducción con IA y subida directa a App Store Connect y Google Play Console. Sin tarjeta de crédito.
Empieza gratis →No tienes que predecir el futuro
Una de las formas más fáciles de sobrediseñar una startup es construir en torno a problemas que todavía no han pasado.
«Puede que tengamos millones de usuarios».
«Puede que tengamos varios equipos de ingeniería».
«Puede que necesitemos escalar este componente por separado».
«Puede que cambiemos de base de datos más adelante».
Todo eso es posible.
Pero posible no significa probable, y probable no significa que tengas que resolverlo hoy.
La arquitectura de una startup debería responder sobre todo a los problemas que el equipo tiene de verdad, no a una versión imaginaria de la empresa dentro de cinco años.
Si algún día hay que dividir el sistema, puedes dividirlo cuando el motivo esté claro.
Hasta entonces, mantener las cosas juntas puede hacer que el desarrollo sea más rápido, la depuración más fácil y el sistema entero más fácil de entender.
Eso no significa ignorar el crecimiento futuro.
Significa aceptar que probablemente todavía no sabes exactamente cómo será ese crecimiento.
Y no pasa nada.
Cada servicio es una responsabilidad más
Es fácil mirar una arquitectura de microservicios y ver un conjunto de piezas pequeñas y bien separadas.
Lo que se pasa por alto es que cada una de esas piezas tiene un costo operativo.
Un servicio necesita despliegue. Necesita monitorización. Necesita logs. Necesita alertas. Necesita configuración. Alguien tiene que entender qué pasa cuando se cae. Alguien tiene que investigarlo cuando su latencia se dispara de repente.
Ahora imagina hacer eso con diez servicios.
Luego con veinte.
Luego con cincuenta.
Para una organización grande, ese trabajo extra puede compensar sin ninguna duda. La independencia entre equipos y sistemas puede aportar suficiente valor como para justificar toda esa complejidad.
Para un equipo pequeño, en cambio, puede convertirse en una distracción.
En lugar de dedicar tiempo a mejorar el producto, los desarrolladores pueden acabar dedicando una buena parte de su tiempo a mantener la maquinaria necesaria para que la arquitectura siga funcionando.
Y ese es uno de los costos menos evidentes de los microservicios.
Puede que el código en sí no sea especialmente difícil.
Es todo lo que rodea al código lo que empieza a sumar.
El monolito modular merece más respeto
El monolito modular está en algún punto entre los dos extremos.
Sigue siendo una sola aplicación, pero no tiene por qué ser una base de código gigante y enmarañada donde todo puede acceder a todo.
La aplicación se puede dividir en módulos lógicos con responsabilidades y límites claros.
Eso permite a los desarrolladores pensar en dominios separados sin meter una frontera de red entre cada uno de ellos.
El desarrollo también puede seguir siendo relativamente sencillo. Ejecutar la aplicación en local es más fácil. Depurar suele ser más directo. Las transacciones pueden ser más fáciles de gestionar. Desplegar no exige coordinar un montón de servicios independientes.
Y hay menos infraestructura que mantener.
Y lo más importante: empezar con un monolito no significa que te quedes atado a él para siempre.
Un monolito bien estructurado puede incluso facilitar un futuro paso a microservicios, porque los límites ya existen.
Si el módulo de facturación acaba siendo la parte del sistema que de verdad necesita escalar o desplegarse por separado, puedes extraerlo.
No tienes que extraerlo todo solo porque una parte necesita cambiar.
Esa es la verdadera ventaja de diseñar buenos límites.
Te estás dejando opciones abiertas.
Entonces, ¿cuándo tienen sentido los microservicios?
No existe un número mágico de usuarios a partir del cual una empresa deba pasar de repente de un monolito a microservicios.
El tráfico por sí solo no basta para tomar esa decisión.
Los microservicios resultan mucho más convincentes cuando distintas partes del sistema tienen necesidades de escalado realmente diferentes, cuando los equipos necesitan desplegar de forma independiente, cuando los límites entre dominios se entienden bien o cuando ciertos componentes requieren tecnologías o infraestructura completamente distintas.
La estructura del equipo también importa.
Una organización con decenas de equipos de ingeniería tiene problemas de coordinación muy distintos a los de una startup con cuatro desarrolladores.
La arquitectura debería responder a esas realidades.
Si separas un servicio porque un componente está causando un problema de escalado real, eso es un motivo.
Si separas un dominio porque varios equipos necesitan trabajar en él de forma independiente, eso es un motivo.
Si lo haces porque «puede que algún día lo necesitemos», quizá merezca la pena esperar.
La mejor decisión de arquitectura suele ser la que resuelve el problema de hoy sin crear cinco nuevos.
La arquitectura más sofisticada puede ser la aburrida
La ingeniería de software tiende a premiar la complejidad.
Un diagrama lleno de servicios, colas, bases de datos, buses de eventos y componentes de infraestructura puede parecer impresionante.
Pero los usuarios no ven nada de eso.
Ven si el producto carga rápido. Ven si sus datos están seguros. Ven si una función responde cuando la necesitan. Ven si el producto transmite fiabilidad.
Para eso está la arquitectura, al fin y al cabo.
A veces eso significa microservicios.
A veces significa un monolito modular.
A veces significa algo intermedio.
El error es dar por hecho que una arquitectura más complicada implica automáticamente un equipo de ingeniería más maduro.
La buena arquitectura no consiste en cuántas tecnologías caben en un sistema.
Consiste en construir algo lo bastante fácil de entender, lo bastante fiable de operar y lo bastante flexible para cambiar cuando cambia el producto.
Quizá por eso algunos equipos están volviendo a los monolitos.
No están renunciando necesariamente a la escalabilidad.
Se están dando cuenta de que la simplicidad también es una forma de escalabilidad, sobre todo cuando lo que tiene que escalar no es solo la infraestructura, sino el equipo que construye el producto.