Monolitos vs. microservicios: ventajas, desventajas y casos de uso

Una arquitectura monolítica es un estilo de organización del software en el que toda la aplicación se construye y se despliega como una única pieza o unidad. Esto significa que los distintos componentes de la aplicación, como la interfaz de usuario, la lógica de negocio de las diferentes áreas funcionales y el acceso a los datos, residen dentro de un mismo código base, se compilan juntos y se ponen en funcionamiento como un solo bloque, habitualmente apoyándose en una única base de datos compartida. Es importante aclarar que monolítico no significa desordenado ni mal hecho: un buen monolito está bien organizado internamente en módulos con responsabilidades claras y fronteras definidas entre las distintas áreas, de modo que el código sea limpio y mantenible; la característica que lo define no es el desorden, sino el hecho de que todo se despliega junto como una sola cosa. La arquitectura monolítica es el punto de partida natural de la inmensa mayoría de las aplicaciones, y tiene ventajas muy relevantes, especialmente en las etapas iniciales y en sistemas de tamaño pequeño o medio. Entre esas ventajas está la simplicidad de desarrollo, ya que todo está en un mismo sitio y no hay que lidiar con la comunicación por red entre partes; la facilidad de despliegue, al tratarse de una única unidad; la facilidad para probar el sistema de extremo a extremo; el rendimiento de las llamadas internas, que son simples llamadas dentro del mismo proceso y por tanto rápidas y fiables; la sencillez para mantener la consistencia de los datos al usar una sola base de datos; y la facilidad para razonar sobre el conjunto del sistema. Sus desventajas aparecen a medida que el sistema y el equipo crecen mucho: puede volverse grande y difícil de mantener, cualquier cambio por pequeño que sea obliga a volver a desplegar toda la aplicación, los equipos numerosos tienden a estorbarse al trabajar sobre el mismo código, escalar obliga a replicar toda la aplicación aunque solo una parte esté saturada, y queda atado a una única tecnología. Aun así, conviene subrayar que muchísimas aplicaciones, incluidas algunas muy grandes y exitosas, funcionan perfectamente como monolitos bien diseñados, y que este estilo sigue siendo una elección válida y a menudo la más sensata.

Los microservicios son un estilo de arquitectura de software en el que una aplicación se construye como un conjunto de varios servicios pequeños, independientes y desplegables por separado, en lugar de como una única pieza. Cada microservicio se encarga de una capacidad concreta del negocio, por ejemplo la gestión de usuarios, el procesamiento de pagos o la administración del catálogo de productos, y funciona de manera autónoma, con su propio ciclo de vida de desarrollo y despliegue, a menudo con su propia base de datos e incluso, si conviene, con su propia tecnología o lenguaje de programación. Estos servicios se comunican entre sí a través de la red, habitualmente mediante interfaces bien definidas como interfaces de programación de tipo REST o mediante sistemas de mensajería, de modo que en conjunto colaboran para ofrecer la funcionalidad completa de la aplicación. La idea de fondo es descomponer un sistema grande en piezas más pequeñas y manejables, cada una con una responsabilidad acotada, que puedan ser desarrolladas, desplegadas y escaladas de forma independiente por equipos distintos. Este enfoque aporta ventajas importantes en sistemas grandes y complejos: permite escalar de forma independiente cada servicio, reforzando solo aquel que está sometido a más carga en lugar de replicar toda la aplicación; posibilita despliegues independientes, de manera que cada equipo puede publicar cambios en su servicio sin tener que coordinarse con los demás ni frenar el trabajo ajeno; ofrece cierto aislamiento de fallos, ya que un problema en un servicio no tiene por qué tumbar todo el sistema; da libertad para elegir la tecnología más adecuada en cada servicio; y favorece la autonomía de los equipos. Sin embargo, los microservicios traen consigo una complejidad considerable, sobre todo de tipo operativo, que constituye su principal desventaja: la comunicación por red entre servicios introduce latencia y posibilidad de fallos, los datos quedan repartidos entre servicios lo que dificulta mantener su consistencia, se necesita monitorización y rastreo distribuidos para diagnosticar problemas que atraviesan varios servicios, y en general hacen falta más infraestructura, más herramientas y más conocimientos operativos. Por ello, los microservicios son una solución potente para determinados contextos, pero no una opción que convenga adoptar de forma indiscriminada.

La comparación entre microservicios y monolito se entiende mejor viendo cómo cada ventaja de un enfoque se corresponde con un coste, ya que no existe una opción universalmente mejor, sino compromisos distintos. Las ventajas de los microservicios frente al monolito son varias. Permiten el escalado independiente, de modo que si un área concreta de la aplicación recibe mucha carga, se puede reforzar solo el servicio correspondiente sin necesidad de replicar toda la aplicación, lo que resulta más eficiente en sistemas con demandas muy dispares entre sus partes. Posibilitan despliegues independientes, de forma que cada equipo publica cambios en su servicio sin coordinarse con los demás, lo que agiliza el desarrollo cuando hay muchos equipos. Ofrecen aislamiento de fallos, ya que la caída de un servicio no tiene por qué derribar todo el sistema. Y dan flexibilidad tecnológica y autonomía a los equipos. Frente a esto, el monolito ofrece sus propias ventajas, que son en gran medida las desventajas de los microservicios: es mucho más simple de desarrollar al principio, más fácil de desplegar al ser una sola unidad, más sencillo de probar de extremo a extremo, más fácil de razonar como conjunto, y evita por completo la complejidad de la comunicación por red y de los datos distribuidos, manteniendo además la consistencia de los datos de forma sencilla al apoyarse en una única base de datos. En el lado de las desventajas, los microservicios pagan un precio alto en complejidad operativa: la comunicación pasa de ser llamadas internas rápidas y fiables a llamadas por red más lentas y susceptibles de fallar, los datos repartidos complican mantener la coherencia, se necesita monitorización y rastreo distribuidos para diagnosticar problemas que cruzan varios servicios, y aumentan la infraestructura, las herramientas y los costes necesarios. El monolito, por su parte, tiene como desventajas que al crecer mucho puede volverse difícil de mantener, que cualquier cambio obliga a redesplegar todo, que los equipos grandes se estorban sobre el mismo código, y que escalar implica replicar la aplicación entera. En resumen, los microservicios compran escalabilidad independiente, despliegue autónomo y aislamiento a cambio de una complejidad mucho mayor, mientras que el monolito compra simplicidad a cambio de límites al crecer, por lo que la elección debe basarse en el tamaño del sistema, el número de equipos y el momento del proyecto.

Conviene plantearse el uso de microservicios en lugar de un monolito cuando concurren ciertas condiciones relacionadas con el tamaño y la complejidad del sistema, la organización de los equipos y las necesidades concretas de escalado y despliegue, y no simplemente por seguir una tendencia. Los microservicios tienden a justificarse cuando el sistema es muy grande y complejo, hasta el punto de que mantenerlo como una sola pieza se vuelve difícil de manejar, y cuando hay muchos equipos trabajando en paralelo que se estorbarían mutuamente si compartieran un único código base, de modo que dividir el sistema en servicios les permite trabajar de forma autónoma, cada uno responsable de su parte, desplegando cuando lo necesitan sin frenar a los demás. También encajan bien cuando distintas partes de la aplicación tienen necesidades de escalado muy dispares, ya que permiten reforzar únicamente el servicio que soporta más carga en lugar de replicar toda la aplicación, lo que resulta más eficiente en costes y recursos. Asimismo, resultan adecuados cuando se requiere desplegar ciertas partes de forma muy independiente y frecuente, o cuando el aislamiento de fallos entre áreas es especialmente valioso. Por el contrario, para un producto nuevo, con un equipo pequeño y en fase de validar la idea, o para un sistema de tamaño modesto y relativamente estable, un monolito bien hecho suele ser la mejor elección, porque aporta simplicidad y rapidez de desarrollo sin la pesada complejidad operativa de los microservicios. El consejo más extendido entre las personas con experiencia en arquitectura es empezar por un monolito modular y bien organizado y evolucionar hacia microservicios solo cuando el crecimiento del sistema y del equipo lo justifiquen realmente, extrayendo como servicios independientes aquellas partes concretas que se beneficien de ello. La razón es que al principio de un proyecto no se conocen todavía con claridad cuáles son las fronteras correctas entre servicios, y partir el sistema demasiado pronto suele producir microservicios mal delimitados que después hay que rehacer, algo costoso. En definitiva, la decisión debe basarse en necesidades reales y presentes, no en modas ni en previsiones inciertas, y conviene recordar que es más fácil dividir un monolito ordenado cuando llegue el momento que recomponer microservicios mal diseñados.

Se recomienda empezar por un monolito, siempre que esté bien hecho y sea modular por dentro, por una combinación de razones prácticas que tienen que ver con la incertidumbre inicial de todo proyecto y con el elevado coste de la complejidad de los microservicios. La primera razón es que al comienzo de un proyecto no se conocen con claridad cuáles son las fronteras correctas entre las distintas partes del sistema, es decir, cómo debería dividirse idealmente en servicios; ese conocimiento se adquiere a medida que el sistema evoluciona, se usa y se comprende mejor el dominio del problema. Si se parte el sistema en microservicios demasiado pronto, es muy probable que esas divisiones resulten equivocadas, dando lugar a servicios mal delimitados que dependen excesivamente unos de otros o que reparten mal las responsabilidades, y corregir esos límites una vez que están repartidos en servicios independientes es mucho más costoso y complicado que reorganizar los módulos dentro de un monolito. La segunda razón es que los microservicios acarrean una gran complejidad operativa, con comunicación por red, datos distribuidos, necesidad de monitorización y rastreo distribuidos y más infraestructura, complejidad que solo compensa cuando el tamaño del sistema y del equipo la justifican; asumir toda esa carga desde el principio, cuando aún no hay ni la escala ni el número de equipos que la requieran, supone pagar un precio muy alto sin obtener a cambio los beneficios, ralentizando el desarrollo inicial en lugar de acelerarlo. La tercera razón es que un monolito bien diseñado, con módulos claros y fronteras internas cuidadas, no impide en absoluto migrar más adelante a microservicios; al contrario, facilita ese camino, porque permite descubrir con el sistema en funcionamiento cuáles son las partes que realmente se beneficiarían de convertirse en servicios independientes y extraerlas de forma gradual cuando la necesidad aparezca. Por todo ello, la estrategia conocida como empezar por el monolito consiste en construir primero una aplicación monolítica pero limpia y modular, validar el producto y comprender el dominio, y evolucionar hacia microservicios de manera selectiva y justificada solo cuando el crecimiento lo pida, evitando así tanto la complejidad prematura como las divisiones equivocadas.

Sí, es perfectamente posible y de hecho habitual cambiar de un monolito a una arquitectura de microservicios más adelante, y esta es una de las razones por las que empezar con un monolito bien diseñado es una estrategia tan recomendada, ya que no se trata de una decisión irreversible ni de una elección de por vida. La forma más sensata de hacer esa transición no es reescribir todo el sistema de golpe, algo arriesgado y costoso, sino evolucionar de manera gradual, extrayendo del monolito aquellas partes concretas que más se beneficien de convertirse en servicios independientes, por ejemplo las que tienen necesidades de escalado particulares, las que cambian con mucha frecuencia o las que un equipo específico necesita gestionar de forma autónoma. Este enfoque incremental permite ir aprendiendo, validando las decisiones de división y limitando el riesgo, en contraste con una migración total de una sola vez. Para que esta evolución sea viable y no traumática, es fundamental que el monolito de partida esté bien construido, es decir, que sea modular por dentro, con fronteras claras entre las distintas áreas funcionales y con un bajo acoplamiento entre ellas; cuando el monolito está bien organizado, esos módulos con límites definidos son candidatos naturales a convertirse en servicios independientes, y la extracción resulta relativamente ordenada. Por el contrario, si el monolito es un amasijo de código enmarañado sin fronteras internas, la migración se vuelve muy difícil, porque no está claro por dónde cortar. Precisamente por eso se insiste en que empezar por el monolito no significa empezar por el desorden, sino por una única unidad bien estructurada. Otra ventaja de posponer la adopción de microservicios hasta que sea necesaria es que, para cuando llega ese momento, el equipo ya conoce bien el dominio y el comportamiento real del sistema, lo que le permite decidir con mucho más criterio cómo dividirlo, evitando las divisiones equivocadas típicas de una separación prematura. En resumen, la transición de monolito a microservicios es una ruta habitual y realista, que conviene abordar de forma gradual y guiada por necesidades concretas, y que se ve enormemente facilitada por haber mantenido desde el principio un monolito limpio y modular.