Desarrollo monolítico e instalación distribuida (o despliegue distribuido)

 Desde hace varios años, se discute en nuestra industria, sobre que forma de desarrollar, instalar, usar y controlar nuestras aplicaciones es la mas adecuada. Hace años casi la unica forma de hacer aplicaciones era de una forma monolíticas, que se desarrollaban y se instalaban todas en una misma máquina. Este esquema es el que nos ha permitido hacer cosas muy interesantes y poderosas. 

Aplicaciones Monolíticas

Las aplicaciones monolíticas, tienen varias ventajas y varias desventajas, como todo en esta vida. 

Por un lado, son las mas fáciles de programar, pues todo ocurre en una misma base de datos, las transacciones terminan bien, o si termina mal, se deshace todo. La consistencia de los datos esta casi garantizada si programamos con algún cuidado. 

La instalación de una aplicación monolítica, es fácil, pues todo se instala en una misma maquina y generalmente se sustituye toda la aplicación. Cuando se va a hacer una instalación, se busca alguna ventana donde se prevea poca actividad del sistema, y se baja la aplicacion vieja y se instala la aplicación nueva con su nuevo esquema de base de datos. 

Desventajas de tener aplicaciones monolíticas es que generalmente se instalan de la forma todo o nada, o sea que se instala toda la nueva version y la anterior deja de funcionar o no se garantiza que funcione. 

Esto hace que no se pueda instalar por partes o que sea muy difícil. Tambien hace difícil los cambios de versiones de las herramientas de desarrollo, pues hay que cambiar de version para toda la aplicación, y hay que testear el 100% de la aplicación para poder instalarla. 

Aplicaciones Distribuidas. 

La aplicaciones distribuidas (los microservicios son una clase de aplicación distribuida) permite dividir un problema en problemas mas chicos, y de esta forma pueden dar mas agilidad a la instalacion de aplicaciones. Puedo instalar solo una parte de la aplicación, en forma independiente de las demás, siempre y cuando respete las interfaces con el resto del sistema. Tambien debo garantizar la disponibilidad de mis servicios con algún tipo de redundancia. 

Las ventajas de las aplicaciones distribuidas son varias, pero agregan una complejidad muy grande en el manejo de transacciones que involucren componentes que estan instalados en servidores diferentes. Hay que ser muy cuidadoso en dividir el problema en subproblemas que sean realmente independientes en sus datos, para minimizar el trafico en la red  y para tener una performance comparable con los aplicaciones monolíticas. Además es difícil (o casi imposible) garantizar una integridad de los datos en el 100% de los casos.

Las aplicaciones distribuidas, facilitan mucho la instalación y la escalabilidad de la aplicacion, a costa de hacer mas complejo el diseño y la operación/monitoreo/solucion de errores de la aplicación. 

Pensando el futuro. 

Supongamos ahora, que tenemos una herramienta de desarrollo, que nos permita modelar la aplicación como un todo (en forma monolítica). Que diseñe la base de datos, haga llamadas entre programas sin preocuparme de que forma la misma va a ser instalada (si en una maquina o en diferentes maquinas). 

Para hacer mas rapido y facil mi desarrollo, puedo modularizar la solución, dividiendo mi problema en varios, pero sigo sin preocuparme como se instalaran los mismos. 

En forma posterior, defino que programas se instalaran juntos en un servidor y que otros programas se instalarán en un servidor diferente. 

Si bien en mi programación simplemente tengo 

-- Programa1

      call Programa2( Parámetros)

Cuando programa1 y programa2 estan en la misma unidad de instalación, esto se resuelve como una llamada normal, local. 

Cuando Programa1 y Programa2 están en dos maquinas diferentes (que probablemente sean dos contenedores diferentes) la llamada se debe resolver como una llamada remota. 

Esto es perfectamente alcanzable con la tecnología actual. 

La herramienta además nos tendría que permitir: 

* Generar las diferentes unidades de instalación en diferentes versiones de la propia herramienta

* Elegir que base de datos (o que tipo de base de datos) usar para cada unidad de instalación

* Elegir plataforma de ejecución de una unidad de instalación (por ejemplo .NET core, Java, Node)

Manejo de Versiones instaladas

* Se debe tener que está instalado y que es lo que voy a instalar, para poder medir las diferencias : 

* Detectar cambios en la interfaz de un modulo o de la unidad de instalación e informarlo

* Ayudar a hacer versiones de mi aplicación que sean compatibles hacia atrás, para facilitar las instalaciones en clusters y a escalonar aplicaciones. 

De esta forma, tendríamos la ventaja de un desarrollo monolítico, pero un deploy distribuido, con lo que podríamos resolver problemas mas grandes, con menos recursos, siendo bastante mas productivos. 

Yo creo que no estamos tan lejos de lograrlo. La empresa que lo logre tiene el futuro asegurado por un tiempo largo.