Arquitectura monolítica

¿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 al respecto, solo diré que mi primer programa en GW-BASIC sobre el sistema operativo MS DOS y lo terminé en 1986, es decir, que mínimo tiene 38 años.

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.

Lección # 1: ¿Cómo hice mi primer programa?

Como yo no sabía programar, mi compañero de Universidad me pasó su código, lo que hice fue escribir línea por línea y luego ejecutarla para ver qué hacía.

Hoy se puede aprender perfectamente de la misma manera, podemos buscar en los repositorios públicos algún programa, del lenguaje que queramos aprender, e irlo descifrando poco a poco, línea por línea.

Importante: Esta metodología de aprendizaje será más útil y efectiva si se maneja los principios de algoritmo y las bases de programación, es decir, entender los for, while, if, etc.

¿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.