¿Monolito o microservicios? Ventajas y desventajas

Escrito por Jose Manuel Reche en 2022-01-19T09:05:28+01:00

Topics: Full-Stack Development , Digital Strategy Consulting

¿Monolito o microservicios? Ventajas y desventajas

¿Monolito o microservicios? Es un tema que ha generado y que aún genera mucho debate en el ámbito de la arquitectura de las aplicaciones. Mientras que las aplicaciones monolíticas han predominado durante mucho tiempo, los microservicios han cambiado esta tendencia, pero eso no significa que los microservicios sean la “bala de plata” para la arquitectura de todas las aplicaciones; en algunos casos pueden representar una mala decisión, sobre todo por una “sobreingeniería” no justificada.

Al fin y al cabo, la respuesta para saber decidir entre una arquitectura u otra es “depende”, tal y como citó Kent Beck: “Any decent answer to an interesting question begins, ‘it depends…’”. Y el “depende” hace referencia a muchos factores que no solo tienen que ser tecnológicos.

Optar entre uno de los dos estilos arquitectónicos debe ser una decisión concisa basada en una serie de factores. Antes de adoptar una arquitectura, debemos pensar qué nos puede aportar con respecto a lo que tenemos actualmente o si puede solucionar algo que no podemos solucionar con la arquitectura actual. Puede que una arquitectura que funcione en una empresa no sea la adecuada para otra o incluso para una misma empresa en distintos proyectos. En ocasiones, algunos optan por implementar arquitecturas con tecnologías que se utilizan en las grandes empresas tecnológicas GAFAM como referente, y no por ello tiene que ser la solución para todos los casos.

Monolito: ventajas y desventajas

Ventajas y desventajas del monolito.

Ventajas

  • Facilidad de despliegue: El despliegue de una aplicación monolítica es muy simple, no requiere de orquestación ni gestión con otros componentes ni aplicaciones.

  • Fácil de someter a pruebas y debug : Todo el código está en una misma aplicación lo cual es fácil de testear, debug y monitorizar.

  • Menor latencia: Debido a que un monolito (a diferencia de los microservicios) no requiere tanta comunicación/dependencia con otros componentes/servicios, la latencia es menor.

  • Agilidad: En algunos casos, por razones de time-to-market, se opta por desarrollar una aplicación en modo monolith first y posteriormente se van migrando aquellos casos de uso que se justifiquen hacia microservicios.
 

Desventajas

  • Compleja de mantener: Si un monolito no está bien diseñado en módulos y lo suficientemente desacoplado, según va creciendo el tamaño de la aplicación puede llegar a representar un alto coste por la complejidad del mantenimiento del código (deuda técnica).

  • Escalabilidad: Para escalar un monolito se debe desplegar toda la aplicación, con lo cual requerimos más infraestructura aun cuando la escalabilidad solo sea requerida por unos pocos casos de uso. 

    Por otra parte, la aplicación debe estar diseñada para ser desplegada en clustering (sin sesiones pegajosas, sin procesos concurrentes que se solapen, etc.).

  • Atada a la tecnología: Cuando se desarrolla un monolito, se establece una tecnología/framework y todo el equipo queda atado a dicha tecnología, lo cual imposibilita el hecho de poder utilizar distintas soluciones tecnológicas (frameworks, librerías, etc.,) en función de cada caso de uso y sus requisitos.

  • Punto único de fallo: En caso de que algo falle en el monolito, podría llegar a afectar a toda la aplicación, lo cual se conoce como un single point of failure (SPOF).

Microservicios: ventajas y desventajas

Ventajas y desventajas de los microservicios.

Ventajas

  • Libertad tecnológica: Debido a que los microservicios son proyectos independientes incluso a nivel de base de datos, da la agilidad para decidir e implantar la tecnología a utilizar en función de los requisitos de negocio para cada caso.

  • Desacoplamiento: Alto desacoplamiento, cada microservicio gestiona su propio dominio sin depender de otros.

  • Escalabilidad: A la hora de escalar, solo se escalan los microservicios que hagan falta, a diferencia de un monolito, en el que es necesario escalar toda la aplicación.

  • Mantenibilidad: Los proyectos basados en microservicios son más fáciles de mantener debido a que, en comparación con un monolito, tienen menos código y son más especializados y específicos. Cada microservicio tiene (debe tener) una única responsabilidad.
 

Desventajas

  • Complejidad: Una arquitectura de microservicios puede llegar a ser muy compleja, debido a que intervienen muchos factores por el hecho de que la aplicación está distribuida en distintos proyectos e infraestructuras en los que hay que tener en cuenta factores distintos, como por ejemplo la comunicación entre los microservicios, seguridad, orquestación, coreografía, resiliencia, latencia, consistencia de los datos, etc.

  • Pruebas y trazabilidad: Al ser un contexto distribuido, el coste para implantar y ejecutar las pruebas es más complicado, y lo mismo sucede con la trazabilidad, lo cual requiere la implantación de herramientas específicas para ello.

  • Consistencia eventual de datos: Debido a que cada microservicio debe tener —o es recomendable que tenga— su propia base de datos para gestionar su dominio, surgen problemas como el caso de la “consistencia eventual de los datos” que el proyecto debe asumir y gestionar.

  • Infraestructura: Los microservicios requieren más infraestructura, sobre todo en lo que se refiere a la comunicación entre los microservicios (East-West traffic), y más aún si se opta por una solución basada en eventos (event-driven microservice architecture).

Solo hemos nombrado algunas ventajas y desventajas para cada caso, pero el listado puede ser más extenso según el tamaño del proyecto y los requisitos técnicos y de negocio.

En resumen, hay muchos factores que intervienen a la hora de decidir entre monolito o microservicios, pero sobre todo no hay que creer que un monolito es la “vieja” forma de desarrollar aplicaciones y los microservicios son la “nueva” forma. Como se ha descrito previamente, la respuesta es “depende”.

Independientemente de si comenzamos con un monolito o microservicio, lo más importante es que el código esté desacoplado y modularizado y que aplique una serie de patrones básicos como los principios SOLID y sus respectivas pruebas, de forma que podamos ir refactorizando la aplicación con facilidad hacia otras arquitecturas además de facilitar el mantenimiento.

Si tienes previsto desarrollar un nuevo proyecto (greenfield) o refactorizar un proyecto legado (brownfield) y no sabes si decidir entre monolito o microservicios, contacta con nosotros; te podemos ayudar tanto si se trata de decisiones técnicas, asesoramiento, auditoría o la implantación de la solución.