Journey to Cloud Tales III – Cumulus, ¿cómo se crean las nubes?

José María Silva Bravo
Application Engineering Services – Practice Leader SPGI
IBM Consulting

En anteriores capítulos expuse cómo emprender un Viaje a la Nube  y las grandes líneas que nos permiten una aproximación eficiente y con garantías de éxito. Ahora toca empezar a aterrizar algunos de los retos planteados. El primer reto se refiere a la identificación de las olas o grupos de aplicaciones y servidores a modernizar y mover de manera conjunta.

Para ello me gustaría introducir el concepto de Cumulus desde el punto de vista meteorológico. Un Cumulus es, obviamente, un tipo de nube que se forma solo, en filas o en grupos, con desarrollo vertical u horizontal y bordes claramente definidos. Pero, ¿a que suena a contenedor?

Desde el punto de vista de modernización a la nube, se trata de un grupo de componentes (aplicación funcional, componentes software e infraestructura) que se encuentran fuertemente relacionados entre sí. Además de presentar el menor número posible de relaciones con componentes pertenecientes a otros Cumulus. Es decir, algo que se podría mover a la nube de manera conjunta y con el mínimo impacto posible en el resto del sistema.

Además de un nombre curioso, Cumulus es una metodología y una serie de aceleradores enfocada a la modernización de sistemas complejos. Nació en 2021, está en proceso de patente y ha recibido uno de los Premios Mundiales de Innovación de IBM.

Obviamente, no voy a contar sus secretos, pero sí voy a exponer los conceptos generales que nos permiten aproximar con éxito la modernización de todo tipo de sistemas complejos.

Antes de comenzar, me gustaría resaltar algo fundamental pero que el abuso de presentaciones hace olvidar: en este tipo de proyectos de modernización no existe la magia. Métodos y aceleradores como Cumulus y, sobre todo, equipos preparados convierten estos proyectos en factibles, reducen significativamente su plazo, coste y riesgo tecnológico, pero siguen siendo proyectos extremadamente complejos.

¿Big Bang o proceso iterativo para la nube?

La primera pregunta es: ¿puedo realizar un proyecto de forma tradicional con un despliegue final en forma Big Bang? Si la respuesta es afirmativa, no necesito complicarme la vida identificando los Cumulus u Olas.

Aunque este enfoque es técnicamente mucho más sencillo, a lo largo de los años se ha ido limitando su uso. Especialmente, por el bajo time-to-market y el riesgo de desviación de las necesidades reales de los usuarios.

Si acometemos el proyecto de modernización de manera iterativa, este enfoque nos permitirá ir generando valor de manera continua desde fases tempranas del proceso, pero a su vez complica enormemente el proyecto:

• ¿Cómo identificar y definir los Cumulus de modernización, es decir, las iteraciones?
• ¿Cómo definir y construir los mecanismos de coexistencia que permitan la comunicación entre lo nuevo y lo antiguo? Este es otro punto crítico y, obviamente, lo trataré en un capítulo específico.

¿Es lo mismo un sistema ‘mainframe’ que un sistema distribuido?

¡La respuesta obvia, inmediata y casi indignada es NO! De hecho, los perfiles humanos, los procesadores, los sistemas operativos, el protocolo nativo de comunicación, los paradigmas de lenguajes de programación y hasta los códigos de página son diametralmente opuestos.

Por un lado, los sistemas mainframe están compuestos por componentes de pequeño tamaño que funcionan en la misma plataforma de forma individual, muy interconectados y en grandes cantidades: decenas de miles de programas y bases de datos, cientos de miles o millones de ficheros y millones de relaciones entre ellos.

En el lado opuesto, un sistema distribuido está compuesto por componentes de tamaño medio o grande empaquetados juntos pero que funcionan en múltiples plataformas formando un sistema también muy interconectado. Servidores donde hay instaladas varias aplicaciones, bases de datos que contienen esquemas de múltiples aplicaciones, etc.

Curiosamente, son sistemas tan opuestos que son idénticos a la hora de afrontar su modernización, específicamente por el gran acoplamiento entre sus componentes que dificulta segmentar o separar en sistemas más pequeños. De hecho, lo que expongo a continuación es igualmente válido para ambas plataformas, solo difieren las herramientas a emplear y los perfiles humanos.

Empecemos haciendo algo insólito: aprendamos de la Historia. Ya hemos vivido unos cuantos procesos de modernización masivos como el llamado efecto Año 2000, el Euro o la migración de ficheros a bases de datos relacionales, donde curiosamente ahora estamos en el proceso contrario. Y aprendamos también del hecho de que aún quedamos algunos (pocos) arquitectos en activo que participamos en esos proyectos.

En esos proyectos, curiosamente, se trataba de modernizar sistemas complejos, muy grandes y relacionados. Para ello había que localizar patrones en el código, modificarlos, probarlos y desplegarlos, ¿suena a algo?

En concreto buscábamos patrones de fechas o importes; ahora buscamos patrones de sesiones de usuario o sentencias específicas. Pero el principio, el reto, ¡y hasta los sistemas a modernizar son en su mayoría los mismos!

¿Pero de verdad, cómo lo hacemos?

Primera regla básica: a mano es imposible. Se necesitan herramientas y aceleradores capaces de lidiar con volúmenes muy masivos de información.

Segunda regla básica: hace falta un equipo experto o, al menos, con el suficiente sentido común como para entender la magnitud de los retos a afrontar.

Tercera regla básica: es imprescindible tener un método. El nuestro, Cumulus, puede ser resumido en tres grandes retos:

1. Identificación de todos los componentes que tiene un sistema y de las relaciones entre ellos.
2. Segmentación del portfolio en función de las relaciones entre sus componentes identificando los Cumulus u olas.
3. Priorización de los Cumulus por factores funcionales, tecnológicos o económicos.

Levantamiento de un mapa de aplicaciones para la nube

Con respecto al primer reto, ser capaz de identificar los componentes y sus relaciones, se trata de una labor que solo puede ser realizada de manera automática mediante analizadores de código capaces de analizar múltiples lenguajes de programación: COBOL, JCL, PL/I, DB2, JAVA, .NET, etc.

Afortunadamente, para acometer los proyectos Año 2000 se crearon herramientas que permitían analizar todos esos tipos de componentes levantando mapas de aplicaciones técnicos de las mismas. Y, aunque la mayoría ha desaparecido, aún existen herramientas herederas de aquellas que permiten efectuar estos análisis automatizados y realizar el descubrimiento de las relaciones y dependencias levantando mapas técnicos de aplicaciones y de sus relaciones.

Sin embargo, aquellos proyectos eran muy tecnológicos. Nuestra gran aportación 20 años después ha sido añadir la capacidad de enriquecer esos mapas técnicos incorporando información funcional, económica o de contexto que nos facilite la toma de decisiones ante diferentes motivaciones.

Ya sabemos qué componentes tenemos, ¿y ahora?

Vamos con el segundo punto, ¿cómo ser capaz de segmentar en función de las relaciones? Siento decir que la solución de que en ciertos casos, el camino más corto entre dos puntos no es la línea recta es difícil de entender y explicar para un arquitecto como yo.

Esta solución se basa en el número de relaciones que existen entre los componentes de las aplicaciones y en esto (y en algoritmos muy complejos bajo patente) se encuentra uno de los principales valores de Cumulus: ser capaz de crear grupos de aplicaciones muy relacionados entre sí y con las mínimas relaciones posibles con aplicaciones de otros grupos. La figura de la derecha muestra un ejemplo real de una división de un portfolio de aplicaciones en varios miles de Cumulus.

Ya tenemos todos los componentes de un sistema, las relaciones entre ellos y hemos dividido en grupos.

Ya tenemos todo dividido, ¿por dónde empezamos?

Buena pregunta, pero ¿por qué queríamos modernizar? ¿Para obtener nuevas y mejores funcionalidades? ¿Para aprovechar capacidades disponibles en nuevas tecnologías? ¿O simplemente porque esperamos obtener una reducción de costes?

Curiosamente, la respuesta a esta pregunta no está muy clara en muchos proyectos de modernización. Se difuminan los objetivos reales del proyecto, eligiendo la priorización según otro tipo de parámetros y evitando obtener los beneficios esperados en el plazo deseado.

Para evitar este problema, inventamos lo que denominamos Índice de Modernización, que marca la prioridad de modernización para todos los Cumulus.

En concreto, este índice es un valor calculado sobre diferentes componentes:

• Factores de negocio: importancia funcional, etc.
• Datos económicos: consumos, número de incidentes, etc.
• Indicadores tecnológicos: complejidad, tamaño, etc.

Su cálculo se basa en la definición para cada propiedad que hayamos podido descubrir o añadir sobre nuestro mapa si se trata de un factor acelerador (recomienda modernizar) o barrera (desaconseja modernizar), añadiendo un peso determinado para cada uno de los mismos.

A partir de ahí, se aplica una, bueno… muchas y muy complejas fórmulas matemáticas que obtienen el valor del índice para Cumulus estableciendo el orden recomendado de modernización.

Dado que normalmente interesará evaluar y conocer diferentes alternativas, se pueden hacer diferentes iteraciones dándole importancia o peso específico a cada uno de esos factores.

Ya sabemos lo que hay que modernizar, tenemos los Cumulus y el orden de las iteraciones de modernización, solo queda lo fácil; modernizar, probar intensivamente, migrar los datos y desplegar en producción.

Pero, antes de llegar a eso, intentemos subir el interés en el siguiente capítulo: ¿de verdad se pueden modernizar aplicaciones mainframe? ¿Y cómo conviven aplicaciones en la nube y en el mainframe?