Arquitectura monolítica, ¿Obsoleta?

¿Por qué el tema?

Porque las organizaciones pueden sentirse que están obsoletas en cuanto al desarrollo de software por tener todavía sistemas monolíticos.

Y es que parece que todo tiene que irse a la arquitectura de microservicios, o como le llaman otros, aplicaciones modernas.

¿De qué trata la arquitectura de monolito o monolítica?

En pocas palabras, todo los módulos, las funciones, la interfaz de usuario, la lógica de negocio, el acceso, la administración, el login y el resto están en una sola (mono) estructura o unidad.

¿Por qué está tan difundida e incrustada en las organizaciones?

Sin investigar mucho sobre las fechas y la historia, solo diré que mi primer programa en GW-BASIC sobre el sistema operativo MS DOS, que era un monolítico lo terminé en 1986, es decir, que esta arquitectura tiene como mínimo 38 años. No pude evitar ir a wikipedia y enterarme que la versión inicia fue liberada en 1983.

¿Cuándo parece que los monolíticos tienen que evolucionar?

Las aplicaciones o el desarrollo de software estaba orientado a solucionar los problemas o a cubrir las necesidades de los usuarios de escritorios y en las empresas, algunos ejemplos a nivel de escritorio están las hojas de cálculos, las aplicaciones para hacer presentaciones o documentos, los juegos para distraerse un rato y descansar del trabajo o de las tareas, llevar las cuentas y los gastos de la casa y así por el estilo.

Casi paralelamente las aplicaciones también ayudaron a automatizar las tareas empresariales, las mismas herramientas de oficina que mencionamos antes, sistemas de contabilidad, de correo, gestión de clientes entre otros.

Unos de los libros que adquirí por www.amazon.com

Desde que tengo memoria, la industria del software siempre ha estado avanzado en metodología, técnicas, lenguajes, compiladores, interpretadores y mucho más, por ejemplo, revisando los libros que estamos pensando en botar, vender o regalar, me encontré uno editado en 1991 titulado «Evolutionary Systems Development».

De manera empírica y mirando atrás durante 20 años, puedo identificar 4 factores que han acelerado de manera exponencial los avances en la industria de la programación y el desarrollo del software, déjame saber si identificas algún otro.

* El acceso a la información, al conocimiento y a la experiencia de otros de manera global a través de Internet.
* El flujo de dinero que a través de los capitales de riesgos y otros han dado a los emprendedores tecnológicos.
* Mayor cantidad de personas han aprendido más rápido y a más temprana edad a programar, facilitando la entrada al mundo del desarrollo de software.
* Los avances en el hardware y en el acceso masivo por menores costos a computadoras y celulares.

¿La evolución del desarrollo web tuvo algo que ver?

Yo respondería con un rotundo si, y tanto que merece un párrafo especial, ya que a finales del siglo XX e inicios del XXI surgieron los primeros frameworks para desarrollar en la web, Ruby on Rails y Django son dos ejemplos, promoviendo la separación de la lógica del negocio y la capa de presentación, esta última evolucionó muy rápido, volviéndola compleja con la popularidad de JavaScript y frameworks como jQuiery que facilitaron el desarrollo de interfaces de usuario dinámicas y responsivas.

¿El resultado?

Como consecuencia de lo mencionado anteriormente, se produjo una serie de fenómenos propio de los avances tecnológicos, a continuación algunos de los efectos y realidades que afectaron la visión sobre la arquitectura monolítica.

* Aumento en la complejidad de las aplicaciones. (ej. mayor funcionalidades, integraciones, escalabilidad)
* Avances de tecnologías disponibles. (ej. contenedores, orquestación, cloud computing)
* Cambio en los modelos de negocios. (ej. desarrollo ágil, DevOps, microservicios)
* Desafíos en el mantenimiento (ej. gestión de cambios, tiempo de desarrollo, escalado limitado)
* Otros factores. (ej. Equipos distribuidos, tolerancia a fallas, automatización)

La realidad de las empresas.

Cuando nos presentamos a las empresas y ayudarles con su transformación digital o tecnológica, con la evaluación de lo que tienen actualmente a nivel de las aplicaciones, es importante entender el papel que las aplicaciones monolíticas juegan en la empresa, así podemos hacer una arquitectura y un diseño ajustado con sus necesidades y su realidad.

Escenario # 1: Una empresa tiene muchos años operando con aplicaciones monolíticas que son el centro de su negocio.

Puede ser una pequeña consultora de contabilidad, una gran empresa petrolera, o inclusive una multinacional.

En este escenario, es importante entender sobre el contrato de mantenimiento, si tiene las últimas versiones, si no han podido actualizarse, si piensan actualizarse a la última versión, si el fabricante existe y si está activo con el producto que le vendieron.

Luego de saber la situación actual, también es importante entender los planes para el futuro, por ejemplo, ¿Tienen pensado migrar a la última versión de la aplicación monolítica? Si no tienen contrato de soporte o mantenimiento, ¿Tienen pensado adquirirlo? ¿Tienen pensado adquirir otro producto para sustituir el actual?

Debemos percibir con las pregunta anteriores la postura tecnológica de los tomadores de decisiones, también su capacidad financiera y la partida presupuestaria para abordar un posible proyecto de modernización, por último, hay que entender el panorama del nivel de los profesionales de tecnología, si tienen departamento de desarrollo, solo de soporte, etc.

También debemos abordar cuáles son los dolores que tiene la empresa por tener una aplicación monolítica, igualmente, aunque no sea fácil o trivial, entender las bondades y todo lo que en un pasado o presente soluciona la solución bajo análisis.

Aunque no será un factor determinante para el análisis, siempre es bueno saber el lenguaje de programación, la arquitectura sobre la cual corre, el sistema operativo soportado, los requerimientos computacionales mínimos para ejecutarse, las dependencias, si está programado para soportar múltiples hilos de ejecución o multi-procesamiento, sobre los procesos de respaldo, la alta disponibilidad, la replicación hacia otros centros de datos, si soporta montarlo en clúster, la base de datos que soporta y así por el estilo

Escenario # 2: Una consultora de TI que ha desarrollado un software muy especializado y lo tiene colocado en muchas empresas y también es el centro de su negocio, (ej: Un software de cobranza bancaria), en este caso, la consultora está ampliando los módulos y funcionalidades de su solución, pero está pensando en actualizar su tecnología hacia contenedores o la nube.

En este escenario aplican las preguntas del escenario anterior, pero cobra mucha importancia el nivel técnico de los desarrolladores, el lenguaje de programación, la disposición y actitud para pasarse de lenguaje, de arquitectura, de framework o en general de tecnología, el pensamiento sobre el cabeza de la consultora y los líderes en cuanto a cómo ven la transformación tecnológica.

También es importante entender sus dolores con el sistema monolítico actual, soporte, actualizaciones, control de licencias, dificultad para encontrar programadores para soportar el sistema actual, o que cobran mucho, todo lo que les duela que sea relevante para ayudarlos a seleccionar la mejor arquitectura o tecnología.

¿Ventajas?

Sip, todo en esta vida tiene ventajas y desventajas, una arquitectura monolítica tiene todavía su espacio o rango de acción.

Por eso el Arquitecto de Software, el DevOps, inclusive, el Arquitecto de Infraestructura, entre otros, deben tener una noción de las ventajas y desventajas de cada arquitectura para poder asesorar, ayudar y servir a las organizaciones.

Ventaja # 1: Simplicidad de desarrollo

Esta es la más obvia, y por eso la presento como la primera, al estar todo en una misma estructura, desarrollar, probar e implementar es más sencillo.

Inclusive, si hay muchos programadores sobre el mismo desarrollo, al incluir la metodología modular, cada programador puede concentrarse en una función o sub-módulo.

También es sencillo, ya que la función principal, main{} llama a las diferentes funciones o módulos sin tener que validar comunicación, simplemente se invoca y listo, se tiene el resultado.

Ejemplo:

main
{
monto = 6000
variable1 = impuesto(monto)
total = variable1 + monto
}

function impuesto (var m)
{i = m * 0.16
return i}

Como pueden notar, la relación entre la función principal y el único módulo o función es directa, no necesita ningún tipo de interface, validación, y eso lo hace más sencillo que una arquitectura de microservicios.

Ventaja # 2: Rendimiento.

Esto parece razonable a primera vista, ¿verdad?

Ya que todos los componente se encuentran en el mismo proceso, como todas las piezas de código se ejecutan en el mismo sistema de cómputo, al no tener que salir a través de la red para complementarse con otro proceso u otra pieza de código, el rendimiento suele ser mejor.

Ventaja # 3: Eficiencia de acceso de datos.

Como todo el código y el proceso es uniforme y único, como el aplicativo tiene acceso a la base de datos, cuando lo obtiene, está disponible para todo la aplicación, para sus sub-módulos o funciones.

Esta característica hace que el acceso a los datos sea eficiente, ya que no tiene que repetir la misma consulta varias veces, también evita los complejos mecanismos de sincronización.

Ventaja # 4: Menor complejidad.

La lógica, la interconexión entre los diferentes módulos o funciones, buscar y hacer traza a los errores entre otras características operativas se simplifican o se facilitan al estar todo en un mismo lugar.

Sobre el futuro, ¿Los monolitos está muerto?