Modernización de aplicaciones

En 2021 inicié un apasionante proyecto de transformación digital, proceso bastante complicadete, que puedo decir que este año culmina.

Este proceso tiene como punto de partida un sistema monolítico, junto con otros satélite que lo acompañan (también monolitos), sistema que no permite alcanzar los objetivos empresariales por sus limitaciones frente las exigencias actuales del negocio.

Fueron 2 los vectores de cambio que establecimos: la modernización de aplicaciones y las aplicaciones compuestas. Este artículo aborda el primero de los vectores: la modernización de aplicaciones.

¿De dónde partimos?

El punto de partida es una aplicación monolítica, que inició su análisis, diseño y desarrollo en el año 1999, altamente acoplada, incapaz de escalar más, con serios impedimentos en los procesos «purchase-to-pay», poniendo trabas a la posibilidad de abrir nuevos canales y mercados, a la distribución de servicios sobre éstos y, especialmente, a soportar las cargas de peticiones que no necesariamente cristalizan en venta.

Evidentemente, hay otros «pain points», entre los que podemos comentar los siguientes:

Evolución de algunos subsistemas costosa en tiempo y dinero, afectando al «time to market» de las necesidades planteadas desde el negocio.
Latencias (que nos lleva a esperas y «time outs»).
Unificación del comportamiento de aplicaciones móviles.
Ampliación de medios de pago.
Falta de «data steewardship» efectiva.
Todas las «-ilities» con las que desayunamos, comemos y cenamos los arquitectos: mantenibilidad, escalabilidad (ya mencionada, pero quería incidir en ella), disponibilidad, extensibilidad, tolerancia a fallos, reusabilidad, modularidad, interoperabilidad, seguridad, etc.

El monolito

Empecemos por el principio: ¿qué es un monolito o aplicación monolítica?

En ingeniería de software, una aplicación monolítica hace referencia a una aplicación software en la que la capa de interfaz de usuario, lógica de negocios y la capa de acceso a datos están combinadas en un mismo programa y sobre una misma plataforma.
Wikipedia

Básicamente, y en nuestras propias palabras, un «totum revolutum», una gran unidad de software autónoma e independiente de otras aplicaciones en la que sobre una sola base se construyen todas las capacidades empresariales y donde el código (normalmente ingente) y la base de datos están acoplados.

Un monolito ni es bueno ni es malo; depende. Tiene algunas ventajas (vale, se me ocurren pocas):

Se despliega una sola componente.
Al ser un bloque, las pruebas de extremo a extremo son “rápidas” y relativamente fáciles de depurar.
Con todo el código ubicado en un solo lugar, es “fácil” depurarlo.

Pero yo le veo muchas desventajas:

Distintos equipos entorpeciéndose porque trabajan paralelamente sobre la misma base de código y modelos de datos, rompiendo unos el código de otros.
Desarrollo más complejo y lento.
Destinar mucho tiempo en pruebas de regresión.
Imposibilidad de escalar componentes individuales; escala todo o nada (muy costoso).
Derivado de la escalabilidad, el rendimiento merma fácilmente ante altas cargas.
Es difícil y caro proporcionar una alta disponibilidad.
Un error en algún módulo puede afectar a la disponibilidad de toda la aplicación.
Limitado por las tecnologías ya utilizadas en él.
Un pequeño cambio requiere el redespliegue de todo.

A mi modo de ver, ¡al monolito ya no hay que darle más de comer!; aumenta la entropía a medida que aumenta su tamaño.

¿Qué es la modernización de aplicaciones?

Simplificando mucho, podemos decir que es el proceso de actualización de las aplicaciones existentes de una organización a un modelo «centrado en la nube» (ojo, que puede ser tu propia nube, no necesariamente un AWS o similares).

Como derivada segunda de lo dicho anteriormente, consiste en tomar las aplicaciones actuales existentes y modernizar su infraestructura de plataforma, su arquitectura interna y/o sus características.

Verás que también se le denomina «modernización de aplicaciones heredadas» (legacy).

Enfoques de modernización de aplicaciones

Podemos llevar a cabo este proceso desde distintas aproximaciones:

Rehost: se traslada la aplicación de su entorno físico o virtual actual a una plataforma IaaS. Se evita realizar cualquier modificación en la infraestructura o en la aplicación que no sea la necesaria para adaptarse al propio entorno de alojamiento.
Revise: se modifica el entorno de infraestructura y el tejido conectivo de la aplicación para que se puedan aprovechar las capacidades de la nube para la automatización, la elasticidad y el uso eficiente de los recursos. No cambia el código de la aplicación principal; utiliza una combinación de IaaS y PaaS.
Rearchitect: se modifica materialmente la aplicación para adaptarla a una arquitectura optimizada para en modo PaaS, haciendo un uso intensivo de las capacidades nativas de la nube.
Rebuild: se empieza desde cero, retirando parte o todo el código existente que acumulado a lo largo de los años, pero conservando alcance y especificaciones y, quizás, el modelo de datos.
Replace: eliminación de la aplicación existente en favor de una solución SaaS, quizás personalizada.

¿Por cuál optamos? Por el más molón como ingeniero: «rebuild». ¡A tomar viento!

NOTA: Si bien en el enfoque rearchitect podríasmos llegar a mantener total o parcialmente el modelo de datos, yo no lo remiendo en absoluto. No es el momento de entrar en ello aún, pero el modelo de datos de un monolito ni sigue Domain Driven Design, ni está pensado para soportar la responsabilidad única, está muy acoplado a transacciones de tipo ACID y un largo etcétera.

El «estrangulador de monolitos»

Tranquilo, no vamos a cargarnos a nadie. Para realizar este proceso aplicamos un patrón de arquitectura que a quien lo bautizó así deberían darle dos collejas: el Strangler Pattern (patrón de estrangulamiento).

La idea subyacente es la de ir contruyendo, de forma gradual e incremental, la nueva aplicación alrededor de la antigua (monolito), reduciendo poco a poco las funcionalidades del monolito en favor de la nueva. Ésta puede contener no solo la funcionalidad que suplen del monolito; también puede tener nuevas funcionalidades que no existían en el monolito.

A medida que se sustituyen las funciones del sistema heredado, el nuevo sistema acaba sustituyendo todas las funciones del sistema antiguo, estrangulando el sistema antiguo y permitiéndonos retirarlo. De forma paulatina, por tanto, una vez que la nueva funcionalidad está lista, se estrangula el componente antiguo, se pone en marcha el nuevo servicio y se da de baja el componente antiguo por completo.

En qué punto del tiempo quieres parar es decisión tuya, como arquitecto, y de la dirección de informática en base, también, a los objetivos que necesitéis alcanzar. No es necesario que el monolito desaparezca por completo. No hay una fórmula matemática que te diga en qué momento ya hay suficiente.

Tampoco es sencillo este proceso. Aquí el arquitecto tiene que hacer un trabajo de cirugía fina, sin extirpar más de los estrictamente necesario (porque te cargas el funcionamiento del monolito), pero sin dejar tejido cancerígeno en el paciente (porque sigues con acoplamientos, código espagueti, etc).

En este sentido, creo que trabajar bajo un modelo de Domain Driven Design es fundamental; dedicaremos un artículo a este concepto, por supuesto. También ayudan en este proceso el uso de «arquitecturas limpias» (clean architectures) y proxies que enruten las peticiones hacia el nuevo servicio o el monolito antes de retirar por completo, del monolito, aquello que hemos sustituido como servicio (también le dedicaremos unas líneas a este otro tema en otro momento).

Conclusión

Los sistemas heredados existen y existirán; las organizaciones de informática deben decidir si conviene modernizarlos, bajo qué estrategia y aportar los medios necesarios.

Realizar cortes verticales al monolito y sustituirlos por una capa de servicios no es baladí, y tiene más de estrategia que de técnica.

En mi caso, estrategias aparte, dotar de los medios técnicos necesarios ha supuesto determinar toda una nueva arquitectura de referencia, que es a lo que quiero apuntar con este y un próximo artículo relativo a aplicaciones compuestas.

Espero que éste y venideros artículos te puedan resultar, como profesional, tan apasionantes como me ha resultado a mí planificar y ejecutar este viaje. ¡Nos leemos!