Journey to Cloud Tales (V): ¿Modernizar un mainframe?

En anteriores artículos planteé diferentes problemáticas y aproximaciones a la hora de modernizar aplicaciones a la nube. Ahora toca escribir sobre el Santo Grial de las modernizaciones: el mainframe, asumiendo que escribir este artículo será como poco polémico. 

Antes de nada, conviene incidir en que cada organización necesita elegir la mejor infraestructura para sus cargas de trabajo críticas. Desde IBM ayudamos a nuestros clientes a gestionar su infraestructura optimizando entre la nube y el mainframe, por ejemplo, para lograr mejoras en seguridad, gestionar el riesgo y abordar las cuestiones regulatorias con rapidez y flexibilidad. Dicho lo cual, es importante clarificar que, como plataforma, el mainframe es posiblemente el sistema más completo que existe: capacidad de procesamiento, fiabilidad, seguridad, sistemas operativos y lenguajes de programación soportados, capacidad de integración y, ligando con mi anterior artículo, sostenibilidad.

Si hablamos de su coste, habría que compararlo con el coste total en cualquier otro sistema o nube para obtener la misma potencia de computación y disponibilidad; el resultado sorprendería bastante o, quizás, no. 

Entonces, ¿por qué modernizar un mainframe?

El mainframe de por sí ya es moderno. Por tanto, sería más exacto hablar de modernizar las aplicaciones residentes en el mainframe o, más concretamente, hablar de modernizar las aplicaciones que fueron desarrolladas hace 20, 30 o más años y aún siguen desarrollándose, manteniéndose y ejecutándose en esta plataforma. 

Lo primero es rendir un homenaje a la plataforma y a las personas que desarrollaron sistemas que siguen funcionando 30 años después, soportando el negocio de las principales organizaciones a nivel mundial. Éste es el motivo claro para que muchas compañías quieran hacer grandes proyectos de modernización y mover las cargas a sus propias plataformas.

Para hacer aún más interesante la ecuación, primero habría que definir qué es modernizar un mainframe y, luego, considerar otra serie de factores: el volumen de componentes aplicativos, la inversión ya realizada, el coste, plazo y riesgo de hacer nuevo o sustituir estas aplicaciones, y muy especialmente los skills o capacidades de las personas que lo gestionan.

¿En qué consiste modernizar un mainframe?

Cuestión básica pero curiosamente sin una respuesta clara; para intentar responder, desde IBM Consulting en España hemos definido un framework de modernización mainframe con múltiples iniciativas pero que pueden resumirse en 6 grandes líneas de trabajo:

• La propia modernización de las aplicaciones y arquitecturas mainframe habilitando las arquitecturas de coexistencia e integración con aplicaciones y sistemas en la nube.
• El concepto de Back-End as a Service o apertura del mainframe mediante la exposición / consumo estandarizado de funcionalidades con APIs y Eventos o la virtualización / federación de fuentes de datos mainframe.
• La incorporación de Prácticas DevOps y el uso de nuevos entornos eficientes de desarrollo y pruebas.
• Acciones de racionalización y optimización aprovechando las nuevas capacidades de la plataforma y permitiendo reducciones de consumo, mejoras del rendimiento, resiliencia y de la calidad. 
• Incorporación e integración extremo a extremo con plataformas cloud (observabilidad, automatización, nuevos roles SRE, etc.)
• Programas de formación y reciclaje profesional.

Estas líneas de trabajo se acometen con expertos, metodología y herramientas específicas, pero en cada una de ellas aún quedan otras muchas preguntas a resolver.

¿El tamaño importa? ¿Cómo de fácil es llevar de verdad una aplicación mainframe a la nube?

Hablar de un core mainframe es hablar de volúmenes de cientos de miles de programas, cientos de millones de líneas de código, decenas de miles de bases de datos, millones de ficheros, millones de relaciones entre objetos software, etc. Y todo extremadamente conectado.

Con estas magnitudes, cabe preguntarse: ¿Cómo comprender estos sistemas tan complejos? ¿Cómo saber lo que hay que modernizar y las relaciones existentes? 

Como ejemplo, en un análisis reciente de procesos masivos mainframe trabajamos con cien mil procesos batch ejecutando más de 5 millones de pasos, accediendo a decenas de miles de tablas DB2 y creando, accediendo, manipulando, archivando y borrando de manera orquestada más de un millón de ficheros de datos en una ventana de tiempo limitada.

¿Cuál ha sido la inversión realizada para construir, mantener y operar estas aplicaciones? ¿Qué pasa con dicha inversión si elimino el mainframe?

Curiosamente, este parámetro es algo que no se suele considerar cuando se plantea modernizar aplicaciones mainframe. Por ejemplo, si asumimos un período de 20 años, al coste de la propia plataforma hay que sumarle el muy superior coste de decenas, centenas y hasta miles de personas diseñando, desarrollando, corrigiendo, probando y operando. Por pequeña que sea la instalación, variaría desde los centenares a los miles de millones de euros en instalaciones grandes. 

Sin embargo, cuando se plantean escenarios de modernización (especialmente en escenarios globales) no se suele considerar reaprovechar esta enorme inversión realizada a lo largo de los años.   

¿Y qué pasa si muevo las aplicaciones a otra plataforma y/o lenguaje de programación?

Es la primera opción que se suele poner encima de la mesa, y la verdad es que es una idea muy atractiva: mover las aplicaciones mainframe a otra plataforma de manera fácil y rápida. Hay dos grandes enfoques y cada uno demanda algunas consideraciones: 

• El primero consiste en lo que podemos llamar Lift&Shift. Básicamente consiste en mover las aplicaciones mainframe sin ninguna o con escasa modificación a otra plataforma que emula los subsistemas del propio mainframe. Pero esta solución no suele ser tan rápida, indolora y barata como parece. Al final, seguimos teniendo la misma aplicación, con la misma deuda técnica y en una plataforma menos eficiente que el mainframe.

• El segundo caso sí que es el Santo Grial de las modernizaciones: ¿convertir desde un lenguaje procedimental a otro orientado a objetos o mejor, en microservicios? Aunque este enfoque puede ser válido para ciertas conversiones, el abismo entre los paradigmas tecnológicos origen y destino puede provocar malas experiencias, especialmente en aspectos relativos a la mantenibilidad y el rendimiento. 

¿Y qué hacemos con las personas que son las que realmente conocen funcionalmente mis necesidades?

La evolución tecnológica ha producido una gran paradoja: hay un grupo de personas con un conocimiento muy exhaustivo del negocio, pero no de nuevas tecnologías; y, en paralelo, se ha incorporado otro grupo de personas muy formadas tecnológicamente, pero sin conocimiento funcional y que tardará muchos años en obtenerlo. 

Ambos grupos, por cierto, hablan idiomas diferentes y no suelen entenderse. 

¿Pero se puede o no se puede?

A pesar de todo lo anterior, no sólo se puede, sino que hasta se deben modernizar las aplicaciones mainframe y las formas de trabajo. Pues con un enfoque adecuado, pueden obtenerse múltiples beneficios en reutilización de funcionalidades y de la inversión, mejora del servicio, time-to-market, reciclaje profesional, reducción de costes, etc.

Pero esto, a su vez, demanda considerar una serie de aspectos:

1. ¿Necesitamos moverlo todo a la nube? ¿Por dónde empezamos?

Evidentemente, no. Deberíamos mover a la nube sólo aquellos componentes aplicativos que den valor añadido al negocio y permitan obtener beneficios a corto / medio plazo con un coste y riesgo aceptable. En general, los candidatos suelen ser aquellos componentes que se encuentran en relación con los usuarios finales (los denominados system of engagement), donde las nuevas tecnologías pueden aportar un grandísimo valor añadido a esta relación.

Pero, ¿cómo identifico qué partes son en concreto? Para ello, expuse en mi artículo Journey to Cloud III – Cumulus, ¿las nubes se crean? expuse método y una serie de aceleradores que permiten determinar por dónde empezar. 

2. ¿Cómo podemos involucrar a los diferentes perfiles?

Afortunadamente, existe un punto donde la colaboración entre personas con conocimiento funcional y aquellas expertas en nuevas tecnologías puede aportar un enorme valor añadido conjunto. Es decir, en el análisis y diseño de las nuevas aplicaciones, especialmente si se utilizan técnicas de diseño basadas en dominios, donde se precisan ambos tipos de perfiles y se comunican mediante un lenguaje común.

Por cierto, suena antiguo, pero por mucha cloud que exista, sigue siendo necesario realizar el análisis y el diseño de las aplicaciones. 

3. ¿Cómo lo probamos?

Todo proyecto de migración / modernización demanda un gran esfuerzo de verificación. Se trata de un aspecto que precisa la definición y construcción de una arquitectura específica de pruebas con diferentes componentes: piezas redirectoras de tráfico, elementos de cargas y descargas de bases de datos, ejecuciones en paralelo, procesos de comprobación de resultados, etc. 

Y suele demandar el aprovisionamiento de entornos físicos y lógicos que sean capaces de asumir unas cargas similares a las productivas, redundando en unos plazos y costes que hay que considerar. 

4. ¿Cómo convivimos entre el mundo cloud y el mainframe?

Hace tiempo que se evolucionó desde la realización de grandes proyectos con puestas en producción globales hacia enfoques iterativos con puestas en producción parciales. Estos permiten obtener resultados de manera continua y reducir el riesgo de estos proyectos.

Aquí surge el gran reto: ¿cómo se desconecta del mainframe una aplicación ultra acoplada, se despliega en la nube y se continúa comunicando de forma lo más transparente posible con el resto de las aplicaciones mediante paradigmas tecnológicos, protocolos de comunicación y hasta códigos de página diferentes? 

De hecho, suele ser la piedra angular y de mayor complejidad técnica de estos proyectos. Como suele decir un insigne compañero, es cómo hacer una operación a corazón abierto mientras se corren los 100 metros lisos. La respuesta a esta cuestión en mi siguiente artículo, Journey to Cloud VI – La máquina diabólica. 

Firmado: José María Silva Bravo, Application Engineering Services-Practice Leader SPGI, IBM
Consulting