Los monolitos no son tus enemigos

Creditos de la fotografía: Stefano Zocca en Unsplash

Recientemente me he leído la segunda edición de Building Microservices Designing Fine-Grained Systems de Sam Newman, ya había leído la primera edición de 2015. Este libro esta publicado por O’Reilly. Gracias a mi suscripción anual y que existen los iPad/Kindle para poder leer, me evito tener que pensar donde meter tantos libros que leo al año.

Esta vez quería ver que había actualizado 6 años en informática dan para mucho y efectivamente había cosas interesantes que añadir a mi lista de conocimiento.

Una cosa que me llamó la atención y que estoy seguro cualquier lector del libro, máxime en ciertos ambientes, pasaría por alto eran una pequeña sección sobre monolitos. Y me dije, tengo apoyarme en esta fuente para hablar sobre ellos y aquí esta el artículo.

Estan siendo estigmatizados a diestro y siniestro. No pasa un día en el cual salga un chiste o algun arquitecto sin mirar más allá diga que debe ser refactorizado y se menosprecie a las personan que trabajan en un tipo de proyecto similar.

Muchas veces se pone en tela de juicio un monolito, sin siquiera haber parado 5 minutos a analizar el porqué de su existencia o por qué un software relativamente nuevo, digamos 1 año, está pensado como un monolito y no es un microservicio. Muchas veces estas opiniones se vierten sin siquiera saber que es un monolito o los tipos de monolito que existen.

¿Qué es un monolito?

Un monolito es una unidad de despliegue. Cuando todas las funciones de un sistema deben implementarse juntas, es un monolito

Los tipos de monolito habituales son:

Monolito

 Es el que todo el mundo tiene en mente y el que todo el mundo cree que existe, pero existen más.

Podrás tener múltiples instancias para paliar el escalado o robustez de un sistema, pero fundamentalmente todo el codigo se encuentra empaquetado en un solo proceso.

Lo habitual es que encuentres dos o más monolitos en un sistema, pero estos a su vez se encuentra muy acoplados.

Este modelo puede seguir usándose en pequeños proyectos, pero bien sabemos que algun día pueden escalar y crecer según la necesidad, lo que nos lleva al monolito modular.

Si, estáis leyendo bien, al igual que otros autores, también defiendo que un monolito no es un error arquitectónico hoy en día, el error es querer meter todo con calzador sin ver cuáles son tus necesidades. Esto me recuerda a la salida de Azure Private Links, más de uno y dos y tres arquitectos he visto recomendar fervientemente esta pieza cuando nunca la has necesitado. Aquí pasa lo mismo: primero ver y estudiar, luego elegir.

Monolito modular

Es una variación del monolito clásico, ya que implementan una serie de subprocesos o modulos separados. Cada módulo trabaja de forma independiente, pero todos han de combinarse para que funcione el producto. Por tanto volvemos al mismo problema: el despliegue.

Podría decirse, que hacer NuGets o NPM o DLLs, no es hacer microservicios, simplemente es modular el condigo. Si has programado en Pascal o Modula, ya lo hacías, es decir, que viene de la programación estructurada.

Uno modelo modular es una opción mejor que el clásico. El problema fundamental que veo es la base de datos, continúa siendo única y aquí vienen los problemas de escalado. Tus modulos pueden escalar, pero luego creas el cuello de botella en las base de datos. Tambien he visto intentar separa la base de datos en partes para que escale, pero no deja de ser casi siempre una base de datos que lo que espera un Id de empresa o cosas similares. Al final lo que se hace es que la Empresa A entra en su base de datos y la Empresa B en la suya. En paralelo se crea una copia de la aplicación y a via un mecanismo de entrada para un Endpoint diferente, cada empresa entra en su ecosistema. O crear una master o una base de datos compartida y luego las de datos fundamental. Esto no es microservicio.

Monolito distribuido

A veces crees que estás haciendo microservicios o un SOA y lo que estás haciendo son monolitos distribuidos, ya que. por ejemplo:

• Un cambio en un servicio requiere implementación en otros.
• Tus «microservicios» están constantemente hablando con otros. Y lo lógico en microservicios es minimizar esto.
• ¿Tus microservicios están compartiendo constantemente tus datos? si la respuesta es afirmativa, no estás haciendo microservicios.
• ¿Es capad de escalar dinámicamente? si, pero sin crear cuellos de botella. Si los creas o constantemente estas arreglando esto, claramente no haces microservicios.
•  Y para finalizar, la señal más clara es si debes desplegar conjuntamente todo. Pues es un monolito.

Este pequeño cuestionario, de muestra que, al hacer un monolito distribuido, estas cogiendo lo peor de ambos mundos y estas generando más problemas que beneficios. Ante un modelo así, lo mejor intentar o bien ir a SOA o bien ir a microservicios, por que quedarse en este modelo es una autentica catástrofe, estas entre algo que ni es SOA ni es microservicio, es un monolito distribuido.

Para mi los grandes problemas de un monolito son: el despliege y las funcionalidades

Aquí es cuando un equipo ve que su trabajo interfiere o no puede avanzar por culpa de otro desarrollador o equipo que no les deja avanzar, que los cambios se aplican en cascada en infinidad de modulos, etc.

A la hora de trabajar es cuando vemos el choque y la lucha constante en el desarrollo de funcionalidades o mantenimiento.

Pero no se queda atrás el despliegue, ya que esto también se vuelve un infierno, son horas y horas, donde un error en una pieza afecta a todo el Delivery.

Mención especial al orden, el maldito orden que viene en un checkpoint de despliegue que nadie se atreve a modificar, si funciona no lo toques y obviamente se meten funcionalidades donde no tocan.

Al final si nadie de preocupa por mejorar esto con técnicas, que existen, una buena división del trabajo y uso con cabeza de Git. De preparar y actualizar el mapa de despliegue, etc. convierten al monolito en un gran problema, cuando la culpa no es de el, si no, del equipo.

Cuando esto es insostenible, comienza a separar y analizar por donde puedes ir creando microservicios.

La vida no es blanco o negro, y un monolito también tiene sus ventajas

Facilitan las pruebas E2E, la monitorización de la aplicación, simplifican la reutilización de codigo o introducir funcionalidades compartidas entre modulos de forma más sencilla y sin grandes quebraderos de cabeza. En definitiva: son simples.

A modo resumen, os dejo la siguiente tabla donde comprar Monolitos con Microservicios

Ahora que sabes que tipo de Monolitos existen. Os translado unas preguntas para que reflexioneis.

Ya has visto pros y contras de monolitos con el supuesto evolutivo: el microservicio; los modelos de monolitos, etc.

Si yo ahora os lanzo estas frases:

• Estas trabajando en un API Rest y has desplegado decenas de Functions para actuar como una Web API, es decir desacoplas toda la API para que la gestione varias Functions. Pero todas van a beber de los datos de un mismo repositorio. ¿Estas haciendo microservicios?
• Estas con muchas funciones y las rompes en varias para trasladar o separa responsabilidad sobre un mismo ecosistema y lo que hacen las funciones es pasar codigo de una a otra. ¿Estas haciendo microservicios?
• Te dicen que estas haciendo microservicios, pero te indican que dos o más piezas llevan un orden y han de ser desplegadas juntas. ¿Estas haciendo microservicios?

Aqui lo dejo.

Conclusión

A veces muchos de los arquitectos con los que hablo, ven esto como obsoleto, que el proyecto es un dinosaurio y lo tratan de forma despectiva o simplemente lo ven como un legacy que se debe evitar.

No comparto mucho esas opiniones, hoy en día existen opciones, una de ellas los microservicios.

Lo que debe imperar es el sentido común, he visto hacer microservicios para un proyecto simple y tardar 10 veces más para algo que tiene fecha de caducidad o en la vida va a escalar por ser un software para 100 usuarios: seamos simples y si un monolito solventa el problema, no lo enturbies con malas decisiones.

Eso de los 100 usuarios, ya sé que estás pensado, que mañana serán 1000, lo que debes es ser claro: el programa no esta pensado para escalar y propones que hacer desde un principio. Presenta los pros y los contras de seguir con el modelo de monolito, si alguien es inteligente intentará cortar el problema de raíz, en caso contrario, crecer y crecer hasta que explote, cuando es tarde… pero muchas veces es tarde por la comodidad del arquitecto, el equipo de desarrollo y operaciones. Una pequeña inversión a tiempo evita una grande a destiempo.

Lo que no tiene sentido que un programa de 100.000 usuarios que estas iniciando ahora, un proyecto greenfield, sea un monolito, esta claro que no va a escalar bien, que acoplar no te permitirá trabajar bien, ser ágil, etc. Aquí es donde el error es tácito y arquitectura esta fallando en la primera jugada.

La vida es gris y el mundo del software también. Nada es bueno o malo, más bien todo es bueno y malo al mismo tiempo.

Aquí mi lanza a todas aquellas personas que están en un proyecto similar, ni tan mal lo hacen ni también lo hacen aquellos que están en microservicios. Son circunstancias y lo mejor es conocer ambos mundos para mitigar lo máximo posible los problemas.

¿Quién sabe? quizá sea algun dia volvamos a los monolitos por qué la complejidad de un microservicio se vuelve insostenible. El desarrollo también se ve influenciado por la moda.