Por Darío León, Director de Aplicaciones de TI – Zurich Colombia
Una gestión adecuada y continua de las arquitecturas permite ejecutar migraciones por fases, conectar el legado con nuevas aplicaciones sin comprometer la operación.
Ejes de análisis
- El legado convive con lo nuevo
- Las APIs desacoplan la arquitectura
- Los datos se independizan
- La transición protege la operación
LLa antigüedad de una aplicación no determina por sí sola que deba ser reemplazada. Existen sistemas heredados que continúan cumpliendo adecuadamente su función, entregando valor al negocio y su reemplazo, dependiendo de las condiciones, podría representar un riesgo innecesario.
Por esta razón, modernizar aplicaciones requiere comprender primero la arquitectura actual de aplicaciones, los procesos que éstas soportan y las dependencias hacia las capas tecnológicas. El objetivo no consiste únicamente en trasladar una aplicación o sus servidores a la nube. Una migración que conserva las mismas estructuras y antipatrones solo consigue cambiar el problema de un lugar a otro sin resolver las dificultades que dieron origen al proyecto.
Cada aplicación necesita una evaluación particular. Según sus condiciones, la organización puede decidir si conviene realojarlo, cambiarlo de plataforma (replatform), refactorizarlo, recomprarlo, retirar, retener o reubicar (7 R de AWS). Un sistema construido con tecnología discontinuada puede requerir una refactorización, mientras otro podría reemplazarse por una solución de mercado. También existen aplicaciones que deben conservarse e integrarse temporalmente porque continúan atendiendo procesos críticos.
El legado convive con lo nuevo
Las aplicaciones monolíticas plantean mayores dificultades cuando sus módulos comparten componentes y, muy comúnmente, bases de datos. En estas arquitecturas, una modificación puede afectar estabilidad de aplicaciones y procesos de negocio que aparentemente no estaban relacionados.
Reemplazar toda la aplicación mediante una migración de una sola vez concentra el riesgo y dificulta el retorno al entorno anterior cuando se presenta una falla.
Una alternativa es avanzar gradualmente mediante el patrón conocido como Strangler Fig o higuera estranguladora. Este enfoque permite extraer funciones específicas del monolito y trasladarlas hacia nuevos servicios independientes (microservicios). Mientras estas capacidades entran en operación, el sistema heredado continúa procesando el resto de las funciones, este enfoque es beneficioso por el bajo riesgo de cara a la disponibilidad y fiabilidad.
A medida que las funcionalidades se trasladan, el alcance del monolito disminuye hasta que puede decomisarse. Este avance por fases evita concentrar los cambios en un solo despliegue y permite regresar al sistema heredado si alguno de los nuevos componentes presenta fallas.
Las APIs desacoplan la arquitectura
Durante la convivencia entre los sistemas heredados y las nuevas aplicaciones, las APIs establecen contratos para el intercambio de información y la ejecución de procesos. Estos contratos evitan que las nuevas soluciones dependan fuertemente de la lógica interna del sistema anterior.
En algunos casos conviene incorporar un patrón de anticorrupción, que funciona como una capa de traducción entre el sistema heredado y las nuevas aplicaciones. Su propósito es adaptar los modelos, términos y valores del monolito para evitar que sus restricciones se trasladen hacia la nueva arquitectura.
También tenemos escenarios dónde un API Gateway puede aportar seguridad, trazabilidad, observabilidad y control sobre la cantidad de peticiones que recibe la aplicación legada, permitiendo habilitar dichas funciones sin necesidad de una refactorización del legado. Además, si la API mantiene un contrato bien definido, cambios sobre las aplicaciones que están atrás de éste pueden realizarse con mayor libertad sin llegar a afectar a las aplicaciones consumidoras.
Continuando con los microservicios, esta arquitectura es una alternativa a escenarios de una sola aplicación de gran tamaño dónde se dificulta la coordinación entre los equipos de trabajo o aquellos dónde se presenta la necesidad de cambios pequeños pero obligan a desplegar todo el sistema monolito. Separar sus funcionalidades por ámbitos permite, además, atender necesidades diferentes y específicas de escalabilidad y disponibilidad. Esta separación también ayuda al aislamiento de fallas, si uno de los módulos presenta un problema, los demás pueden continuar operando.
Los datos se independizan
El desacoplamiento también comprende los datos. Es común el escenario dónde varias aplicaciones utilizan y comparten diferentes bases de datos de forma directa o incluso indirecta mediante herramientas como db links, linked servers, etc. esto supone un reto al momento de desacoplar y subir las bases de datos a la nube, pues el movimiento de una base de datos puede desestabilizar el funcionamiento de las aplicaciones, para ello es necesario tener actualizada la arquitectura de aplicaciones y datos antes de proceder con la migración.
Por otro lado una arquitectura destino basada en microservicios, condiciona a que cada servicio mantiene sus bases de datos independientes del reto, esto puede implicar que los datos se repliquen entre bases de datos mediante un bus de eventos o integraciones a través de APIs. Se debe tomar en cuenta que no todas las operaciones necesitan que la información se actualice al instante en todos los sistemas, en algunos casos es aceptable que el dato llegue al otro sistema dentro de un tiempo razonable, hasta alcanzar una eventual consistencia. Esta flexibilidad debe analizarse de acuerdo con las necesidades de cada proceso.
Con lo anterior en mente, es natural que durante un proyecto de migración y desacople, parte de los datos permanecen en los sistemas locales mientras otra se traslada hacia las nuevas plataformas. La información alojada localmente disminuye progresivamente, mientras aumenta la que se encuentra en los nuevos servicios y bases de datos en nube.
La transición protege la operación
La modernización de sistemas críticos requiere preservar la continuidad de los servicios. No siempre es posible garantizar una transición sin períodos de indisponibilidad, pero se pueden establecer alternativas para recuperar la operación cuando se produce una falla.
Los mecanismos de failover y rollback permiten mantener temporalmente el sistema nuevo y el heredado, dirigir determinadas transacciones hacia cada uno y regresar al estado anterior cuando algo no funciona correctamente.
Este proceso puede avanzar con mayor granularidad: algunas funcionalidades o transacciones se trasladan hacia el nuevo sistema, mientras otras permanecen en el legado. La migración continúa progresivamente hasta incorporar la totalidad de las capacidades.
Antes de definir la hoja de ruta también se deben identificar las dependencias de las aplicaciones. Durante estos proyectos pueden aparecer conexiones no documentadas con sistemas de archivos compartidos o enlaces entre bases de datos. Estas relaciones pueden modificar el cronograma e incluso volver inviable una migración que inicialmente parecía sencilla.
Una evaluación de las arquitecturas permite conocer estas dependencias y plantear una estrategia de migración realista. La disciplina de arquitectura empresarial habilita a las organizaciones a estar preparadas ante estos retos, y a plantear la hoja de ruta tecnológica.
Las áreas de negocio también deben participar en el proyecto. Su intervención permite aprobar que las aplicaciones funcionan de acuerdo con sus expectativas antes de su paso al nuevo entorno. El respaldo del nivel ejecutivo contribuye a que la modernización se gestione como una iniciativa organizacional y no únicamente tecnológica.
Conectar los sistemas heredados con nuevas aplicaciones requiere avanzar por fases y evitar que todos los cambios se concentren en un solo despliegue. Cada etapa necesita una alternativa de retorno ante posibles fallas y la participación de las áreas de negocio en la validación de las nuevas aplicaciones. De esta manera, la organización puede incorporar nuevas capacidades mientras mantiene sus procesos críticos en operación.
