Arquitectura Monolitica

 En los últimos tiempos, hemos escuchado muchas opiniones sobre cómo es conveniente diseñar nuestras aplicaciones, desde el punto de vista de su arquitectura en la ejecución.  Históricamente las aplicaciones eran monolíticas (una aplicación que se instalaba en una computadora y hacia todo lo que necesitaba) y en forma más recientes se esta optando por hacer aplicaciones distribuidas en varias computadoras, dividas en servicios independientes (algunos lo llaman microservicios).

Voy a hacer una comparación sencilla de una arquitectura monolítica y una arquitectura de microservicios, viendo sus beneficios y sus desventajas. 

Beneficios de una arquitectura monolítica

Sencilla de desarrollar. 

No hay que pensar demasiado donde desarrollo una nueva funcionalidad. Todo se programa en la misma KB.

Sencilla de instalar. 

Se instala todo junto en una misma instalación.

Sencilla de escalar. 

Si necesito mas potencia, puedo replicar una máquina que ya tiene la aplicación funcionando y si me aseguro que un usuario siempre es atendido por un servidor durante toda su sesión, no tendría grandes problemas.

Fácil de monitorear

Al tener todo concentrado en una única aplicación, es sencillo encontrar cual es la parte que está teniendo problemas, pues todo está centralizado.

Testeo funcional es mas fácil.

Como todo esta concentrado en una aplicación, si la pruebo, ya pruebo que todo funciona bien.

Desventajas de la aplicación monolítica. 

Tamaño y complejidad limitadas. 

Las aplicaciones crecen a tal punto que por su tamaño y complejidad son difíciles de entender y los cambios no pueden ser hechos en forma correcta y rápida.
El desconocimiento (o mal entendimiento) de la aplicación produce miedo que los cambios afecten a la aplicación y por lo tanto se realizan muchas tareas de testing manual con cada liberación.

El tamaño de la instalación puede hacer lento la instalación / build all / etc. enlenteciendo el desarrollo y dificultando el uso de DevOps.

Fiabilidad de la aplicación. 

Un problema de performance o consumo desmedido de recursos (memoria, lecturas en disco, bloqueos en la base de datos, sentencias lentas) puede dejar a toda la aplicación fuera de servicio.

Innovación tecnológica. 

Al ser una aplicación monolítica, es mas difícil hacer innovaciones tecnologicas.
Por ejemplo, si hay que cambiar la base de datos, hay que hacerlo para toda la aplicación.
Si hay que cambiar instalar una versión nueva de GeneXus, hay que hacerlo para toda la KB y no se puede hacer en forma escalonada. Las tareas de build/pack/deploy/test llevan mucho tiempo y conllevan un gran riesgo porque es difícil garantizar que todo va a funcionar bien en la nueva versión.

Beneficios de los microservicios. 

Fáciles de entender. 

Al atacar problemas mas chicos, los servicios son mas fáciles de entender, por lo tanto de desarrollar y de mantener.

Independencia entre servicios. 

Es posible desarrollar cada uno de los servicios en forma independiente (siempre que mantengan y respeten las interfaces que publican).
Esto da muchísimas ventajas en la elección de que herramientas utilizar para el desarrollo, permite crear grupos mas chicos de desarrolladores, hacer cambios tecnologicos mas rapido.
Además cada servicio puede ser optimizado y escalado en forma independiente de los demás, posibilitando un buen uso de los recursos existentes. 

Desventajas de los microservicios

Complejidad de la arquitectura. 

Al tener servicios independientes, vamos a tener que elegir de que forma van a conectarse dichos servicios, con comunicaciones entre procesos (rest, soap, otros) haciendo que la arquitectura quede bastante complicada.

Múltiples base de datos

Si cada servicio es independiente de los demás, vamos a tener diferentes bases de datos para cada servicio. Esto trae problemas de varios tipos, como pueden ser problemas de performance para leer datos que estén en diferentes servicios. Como cada servicio se encarga solo de la integridad de sus datos, el manejo de transacciones que afecten mas de un servicio, es responsabilidad de la aplicación (y no de la base de datos) agregando complejidad a la misma. 

Más complejo de probar. 

Si bien la prueba unitaria dentro de cada servicio es más fácil, la prueba de la aplicación basada en microservicios es bastante más compleja y necesita de mucha más coordinación y programación. 

Manejo de requerimientos

Cuando se tiene un cambio que involucra a muchos servicios, los mismos deben realizarse en forma coordinada y la instalación también debe hacerse en forma coordinada, agregando costos al proceso de instalación.

Instalación compleja. 

Al tener muchos servicios, es necesario tener automatizado el proceso pues si no se vuelve inmanejable. Además es mucho mas difícil el saber en que version esta la aplicacion, pues todos los componentes evolucionan en forma independiente, haciendo que la detección y reproducción de los problemas sea una tarea compleja.