Últimamente estamos viendo mucho el término monolito modular, pero qué es? porque lo estamos viendo tanto últimamente? Aquí veremos que es, los motivos y diferentes tipos de arquitecturas de sistemas que se ven hoy en día.
Índice
1 - Qué es un monolito?
Antes de explicar el monolito modular, siento la obligación de al menos, explicar el monolito.
En el post sobre microservicios ya vimos qué es un monolito y sus características, etc, así que lo resumiré muy fácil. un monolito, o una aplicación monolítica es una aplicación que contiene toda la lógica de negocio, todo el frontend, toda la base de datos, etc.
Estas aplicaciones suelen estar caracterizadas por ser muy grandes, necesitar mucho mantenimiento, y por supuesto la complejidad de tener que desarrollar en ella, porque en circunstancias normales, no hay separación de dominios, y todo el mundo accede a todas partes, desde cualquier parte, etc.
El problema principal, es lo que acabo de mencionar, absolutamente todo está interconectado y cambiar funcionalidades es muy difícil porque afecta a otras partes del sistema que no tendría porque hacerlo, pero al estar todo tan conectado, pues lo hace.
Esto hace que el desarrollo sea una pesadilla, y hoy en día sorprendentemente seguimos viendo código así, de hecho es mucho más común de lo que parece.
El problema principal de esta arquitectura es que “nadie” es el dueño de nada. Por ejemplo, cualquiera puede actualizar cualquier registro de la base de datos desde cualquier parte, etc. Lo cual, hace muy difícil mantenerlo todo, porque por ejemplo si quieres modificar algo que ya existe para añadir una validación o para cambiar una columna o algo, al final es un trabajo muy grande en vez de un simple cambio que sería si se respetaran los límites de lo que pueden tocar.
2 - Qué es un monolito modular?
Un monolito modular, es un monolito creado bien y con cabeza y no a la locura.
La principal diferencia es que en los monolitos modulares tienen los límites de cada sección totalmente diferenciados.
Arquitecturalmente sigue siendo una única aplicación pero sus límites están diferenciados lo que evita la gran mayoría de problemas que los desarrolladores tienen que enfrentarse a la hora de realizar cambios en el monolito.
Cuando decimos que los límites están diferenciados nos referimos, sobre todo, a que tienen la capa de lógica separada. La capa de UI o la propia base de datos pueden estar separadas o no, ambas opciones tienen pros y contras. Pero la principal, que es la capa de lógica está separada.
Luego cada módulo tiene una interfaz o punto de entrada para que otros módulos puedan consultar, cambiar información, etc y no hacerlo directamente en la base de datos.
Esta es la característica principal de los monolitos modulares, ayudar en el desarrollo. A la hora de despliegue de la aplicación sigue teniendo los mismos pros y contras que un monolito, sigue teniendo los problemas para escalar, o bueno que no se puede escalar solo una parte; los monolitos modulares estan muy fuerte ligados a Domain Driven Design, con la limitación de los dominios etc.
En mi opinión, actualmente esta debería ser la opción a elegir si tienes que hacer un monolito, hacerlo modular, crear un monolito de los de antes, es bueno, un suicidio a largo plazo.
3 - Microservicios
Ya tengo un post donde explico qué son los microservicios así que aqui no vamos a entrar en detalle, simplemente un resumen, pequeños servicios que se comunican entre si y la característica principal es que cada uno tiene su propia base de datos, su propia capa de negocio, etc, en resumen, son sistemas aislados pero que disponen de una puerta de acceso para que otros servicios puedan consultar su información.
Esta consulta de información se puede hace a través de comunicación síncrona como rest o comunicación asíncrona como pueden ser el patrón productor consumidor.
4 - Microlitos
Mención especial a los microlitos, y que son los microlitos dirás. Es una palabra que me he inventado para definir esos proyectos que los jefes llaman microservicios pero que son tan grandes o más como un monolito, que tiene las desventajas tanto de los monolitos como de los microservicios y todo porque el desarrollo se ha hecho mal, muy mal, y sin pensar.
Estoy seguro de que todos los que estáis leyendo esto, tenéis situaciones donde habeis trabajado con sistemas así.
5 - Qué es serverless?
Para resumir rápidamente lo que es serverless, podemos decir que es la forma en la que ejecutamos aplicaciones sin tener que administrar ningún servidor.
Obviamente no se ejecutan en el aire, sino que el servidor suele estar administrado por un proveedor de servicios, ya sea Azure, amazon, google cloud, etc, son ellos los que ponen la infraestructura y tu pagas por su uso, obviamente en este precio vienen cosas como el escalado, availability, etc.
Por ejemplo las Azure functions o las Lambda functions son la forma en la que Azure y AWS ejecutan código funciones en su infraestructura (hay más, pero como ejemplo) tu creas tu pequeña aplicación en el lenguaje que te guste y lo subes al servicio, y solo vas a pagar cada vez que se ejecute, si se ejecuta 1 vez al mes, pues va a ser casi gratis, y si se ejecuta 1000 veces por segundo, pues te va a costar una pasta.
Esta forma de desarrollo es conocida como “cloud-native development” es la más moderna, la que más responsabilidades quita del equipo de desarrollo y por supuesto la más cara.
Y lo más común en el mundo real es encontrar un mix de cloud native junto con arquitecturas como microservicios (principalmente en kubernetes) o incluso un monolito.
6 - El auge del monolito modular
El motivo principal por el que he creado este post es por el auge de los monolitos modulares, si habéis visto cualquier charla en los últimos 12 o 24 meses os habréis dado cuenta que se están mencionando cada vez mas y mas, pero Porque es esto?
El motivo es claro y simple manager microservicios es complicado en cierta medida y un monolito es mucho más simple, además en caso de necesitarse si hemos creado el monolito modular bien, este podrá ser “partido” con facilidad en microlitos y luego cada microlito en su respectivo microservicio en caso de ser necesario.
Yo personalmente he trabajado en un proyecto así, y es mucho más sencillo que dividir un microservicio como tal.
