Refactorización Automatizada de un Mainframe del New York Times hacia AWS con Modern Systems

Por Michael Buzzetti, Ingeniero en Jefe en The New York Times,
Barry Tait, Director de Modernización y Estrategias en la Nube en Modern Systems,
y Phil de Valence, Solutions Architect para Mainframe Modernization en AWS

The New York Times tenía una carga de trabajo de negocios crítica ejecutándose en un mainframe como sistema central de TI, soportando la plataforma de entrega diaria de su periódico.

Ellos trabajaron con Modern Systems, un socio de AWS Partner Network (APN) Select Technology, para transformar con éxito su aplicación legada basada en COBOL, en una aplicación moderna basada en Java, que hoy se ejecuta en Amazon Web Services (AWS).

Mediante una innovadora refactorización automatizada, la aplicación se modernizó a código orientado a objetos, y los datos se transformaron de archivos indexados legados a una base de datos relacional.

Esta publicación describe el proyecto, incluyendo el proceso de refactorización automatizado y la arquitectura de AWS, así como las lecciones aprendidas, los resultados comerciales y los futuros planes tecnológicos.

The New York Times Contexto y Objetivos

The New York Times es un periódico estadounidense con influencia y lectores en todo el mundo. Fundado en 1851, el periódico ha ganado 125 premios Pulitzer, más que cualquier otro periódico. The Times ocupa el puesto 17 en el mundo por circulación y el segundo en los Estados Unidos.

La aplicación principal de la compañía gestiona la entrega diaria a domicilio del periódico desde 1979, respaldando una línea de negocios por valor de más de $ 500 millones anuales. Esta representaba años de experiencia y conocimiento acumulados y, sin embargo, se resistía significativamente a su modificación y evolución.

Además, el mainframe Z de IBM que ejecuta el sistema operativo z / OS era costoso de operar en comparación con las plataformas más modernas que habían evolucionado en la compañía. Necesitaba un proceso de modernización que redujera los costos operativos y habilitara la convergencia hacia una plataforma digital con la plataforma de entrega a domicilio.

Entre 2006 y 2009, tuvieron un intento fallido de reescribir manualmente la aplicación de entrega a domicilio. En 2015, una evaluación de enfoques alternativos determinó que un segundo intento de volver a desarrollar la aplicación habría sido mucho más costoso, y una alternativa de hacer un re-hosting emulado habría bloqueado datos en tecnología propietarias.

Con la creciente presión para reducir rápidamente los costos, la estrategia elegida fue migrar el código y los datos con refactorización automática. Este enfoque prometía equivalencia funcional, menor costo operativo y una integración fácil con las tecnologías modernas.

Fuente de Carga de Trabajo de Mainframe

La aplicación de mainframe denominada CIS en el mainframe y renombrada como Aristo después de la migración, ejecutó funcionalidades críticas para el negocio como cobro, facturación, cuentas de clientes, enrutamiento de entrega, catálogo de productos, precios e informes financieros.

CIS era una aplicación CICS / COBOL basada en z / OS con una interfaz BMS-based 3270 para acceder a los datos del negocio VSAM KSDS. El procesamiento por lotes (batch) fue soportado por procesos JCL con CA7 para su programación.

En 2015, CIS había crecido a más de dos millones de líneas de código COBOL, 600 trabajos por lotes y 3.500 archivos enviados diariamente a consumidores y sistemas. Se hizo uso de alrededor de 3 TB de datos activos, compuestos por 2 TB de archivos VSAM, y 1 TB de archivos secuenciales QSAM. Usó 20 TB de respaldo en almacenamiento en frío.

Conversión Automatizada con Refactorización

The New York Times seleccionó un enfoque de conversión automatizado, que conserva la equivalencia funcional y la lógica comercial crítica, al transformar las aplicaciones core legadas en aplicaciones basadas en lenguaje Java orientado a objetos, haciéndolas refactorizables y mantenibles. El código se analiza durante la evaluación para determinar que tan preparada se está para ser migrado a la nube y el esfuerzo requerido para obtener el nivel deseado de elasticidad (es decir, escalabilidad horizontal y escalabilidad vertical) requerido por las cargas de trabajo de la aplicación.

La solución de software COBOL-to-Universal Solution (CTU) de Modern Systems soporta componentes de aplicación COBOL basados en mainframe típicos, incluidos CICS, JCL y utilidades comunes, como IDCAMS y SORT, además de repositorio de datos como DB2 para z / OS, Bases de datos IMS, VSAM e IDMS.

The New York Times usó CTU y siguió una metodología de ocho pasos:

Figura 1 – Pasos de refactorización automatizados.

• Paso 1 Se realiza un inventario automatizado del mainframe, completando un repositorio de componentes a ser migrados.
• Paso 2 consiste en un análisis detallado de las aplicaciones, modelo de datos, preferencias de arquitectura, estilos de programación, conexiones de bases de datos, manejo de errores y opciones de refactorización. Todo esto lleva a la definición de cómo fragmentar la transformación del código con paquetes de trabajo y la estrategia de prueba general.
• En el Paso 3, para cada paquete de trabajo, el modelo de datos es definido y creado en la base de datos destino.
• El paso 4 genera automáticamente programas y procesos para descargar, transformar, validar y cargar datos desde el repositorio de datos de origen a la base de datos destino.
• En el Paso 5, la CTU de Modern Systems se usa para realizar ingeniería inversa del código COBOL en un lenguaje intermedio y luego para realizar ingeniería directa del código Java objetivo.
• El paso 6 realiza pruebas de regresión para cada paquete de trabajo, asegurándose de que haya una equivalencia funcional entre los programas de mainframe de origen y el nuevo código Java.
• El paso 7 es el proceso de ejecución de la prueba de aceptación del usuario.
• En el Paso 8, una vez que estas pruebas son exitosas, se lleva a cabo la transición a la producción.

Usando CTU de Modern Systems, la aplicación Java resultante es orientada a objetos y separada en tres capas: lógica de presentación, lógica de negocios y acceso a datos.

Para mantener la misma experiencia de usuario, los mapas CICS BMS se migraron a páginas web equivalentes que imitan lo más cerca posible a las pantallas 3270 originales. Cada programa COBOL se convirtió en una clase Java, y JCL se convirtió en XML JSR-352 utilizando el Spring Batch runtime para Java. Los archivos VSAM KSDS se migraron a una base de datos relacional de Oracle. Durante el proceso de refactorización, se analizaron todos los registros VSAM y se generó un DDL para cada uno de los layouts elegidos.

La tabla de la Figura 2 muestra el mapeo de tecnología entre el stack legado de mainframe y el stack de AWS destino.

Figura 2 – Mapeo de tecnología de origen y destino.

Los componentes de reemplazo se desarrollaron en situaciones donde las dependencias de aplicaciones legadas no eran compatibles con el conjunto de herramientas de Modern Systems (por ejemplo, REXX, GVEXPORT), cuando los paquetes de software estándar no estaban disponibles como un sustituto, o si tenía más sentido hacer uso de capacidades del nuevo entorno (copias de seguridad de la base de datos del proveedor y puntos de restauración, snapshots del sistema de archivos, etc.).

Prueba de Equivalencia Funcional

Era crítico tener equivalencia funcional entre la aplicación Java y la aplicación COBOL. Los grupos de componentes reunieron elementos relacionados que serían ejecutables y comprobables en conjunto como una sola entidad a través de interfaces de acceso externo, como servicios web, pantallas de interfaz de usuario, tablas de bases de datos y archivos.

Las pruebas representaron aproximadamente el 70-80 por ciento del tiempo dedicado al proyecto. El proceso de prueba se dividió en etapas, con cada etapa aumentó progresivamente en alcance y nivel de dificultad el aislamiento de la causa raíz de las fallas en las pruebas.

• Etapa 1 Prueba previa a la entrega: Realizado por Modern Systems antes de entregar el código refactorizado.
• Etapa 2 Validación de migración de datos: Verificar que los datos son los mismos entre el VSAM de origen y la base de datos relacional de destino.
• Etapa 3 Prueba de grupo de componentes: Verificar el comportamiento funcional con un trabajo por lotes, una o más pantallas, una llamada de servicio web.
• Etapa 4 Prueba de Regresión del Proceso por Lotes: Usar datos de prueba estáticos (exactamente los mismos datos de prueba todos los días) para verificar el proceso por lotes de extremo a extremo y realizar pruebas de regresión.
• Etapa 5 Prueba de comparación del proceso por lotes: Usando datos de prueba dinámicos para verificar el lote de extremo a extremo con los datos actuales del día, y comparando la salida entre sistemas legados y sistemas modernizados.
• Etapa 6 Prueba de rendimiento del proceso por lotes: Usando datos de producción.
• Etapa 7 Integración del sistema: Esto se realizó en colaboración con otros equipos y sistemas dentro de la organización. Las nuevas transacciones se ingresan a través de los sistemas del cliente, se procesan por lote y fluyen a los consumidores intermedios a través de informes y feeds de archivos.

Para estas etapas, la cobertura de la prueba debe ser alta. Puede ser muy lento y complejo crear casos de prueba, especialmente para trabajos por lotes. La automatización fue crítica para lanzar y analizar casos de prueba repetida y rápidamente.

Arquitectura de AWS Objetivo

A medida que avanzaba el proyecto, The New York Times se basó en su estrategia general de data center para hacer de la nube el entorno de implementación preferido.. Después de menos de un año de ejecución en un data center privado, Aristo fue migrado a AWS. El equipo había adquirido un conocimiento significativo de cómo se veía una migración exitosa, permitiendo una migración a AWS con un impacto mínimo en el negocio.

Figura 3 – Componentes de Arquitectura de Aristo AWS de Destino.

Como se muestra en Figura 3, una vez migrado a AWS, el sistema se dividió en cuatro componentes principales:

• El sistema Front End proporciona a los operadores internos la capacidad de administrar suscripciones de entrega a domicilio.
• El sistema API proporciona servicios web SOAP a otros sistemas.
• El sistema de reportes crea informes para el departamento de finanzas.
• Batch es el sistema principal donde se ejecutan todos los trabajos nocturnos. Los trabajos pueden ejecutarse en cualquier instancia y el origen y el destino de los datos del trabajo se almacenan en Amazon Elastic File System (Amazon EFS)

Tanto el API como los sistemas front-end están dentro de los grupos de Auto Scaling, lo que brinda la capacidad de responder a una gran cantidad de solicitudes. En estado estable, el sistema API usa cuatro instancias m5.xlarge y el sistema Front End usa dos instancias m5.xlarge. El sistema de reportes también utilizan dos instancias m5.xlarge. El sistema Batch es mucho más grande con tres instancias m5.4xlarge debido a la gran cantidad de cálculos necesarios para ejecutar los trabajos.

Para acelerar la entrega de lanzamientos, se creó un Pipeline de Integración continua y Entrega continua (CI / CD) que incluye:

• Gradle para la construcción y el empaquetamiento de artefactos.
• Artefactos para el almacenamiento y promoción de artefactos.
• Jenkins para despliegue y orquestación.
• Ansible para la gestión de la configuración.
• HashiCorp Vault para la gestión de secretos.

Cronología de la migración

La transformación de la aplicación que impulsa la plataforma de entrega a domicilio comenzó en 2015. Fue un proceso de dos fases.

Refactorización Automatizada

Esta fase duró alrededor de dos años e incluyó tanto la transformación de COBOL a Java como la conversión de la base de datos VSAM a relacional, lo que resultó en el lanzamiento de la aplicación Aristo en producción on-premises.

Alrededor del final de esta fase, The New York Times anunció su estrategia en la nube que impacta el futuro de la plataforma Aristo y desencadena la siguiente fase.

Migración a AWS y Mejoras

Una vez que la aplicación fue probada y estabilizada, el trabajo comenzó en agosto de 2017 para mover la aplicación a la nube de AWS. Este fue un proyecto de ocho meses, que también incluyó los siguientes cambios:

• De Oracle RAC a Oracle EE.
• De Isilon a EFS.
• Actualización de Control-M de versión 7 a 8.
• Actualización de FTP a SFTP / S3.
• Reconstrucción del Pipeline de CI / CD (de Puppet a Ansible).

Figura 4 – Línea de tiempo de migración de Mainframe a AWS.

Una vez en producción en AWS en marzo de 2018, Aristo se benefició del mantenimiento y las mejoras, incluida promoción de código, expansión de tablas, la entrega a domicilio premium (HD) con nuevas ofertas digitales y en papel, y las optimizaciones de costos de AWS.

Mirando hacia el futuro, The New York Times se centra en estas mejoras futuras:

• Desglosando el monolito de la aplicación en microservicios.
• Convergencia continua de las capacidades de la plataforma de suscripción digital, incluidos pagos, catálogo de productos, cuentas de clientes, contabilidad financiera.
• Desarrollar nuevos servicios basados en Java junto con el código convertido.
• Facilitar el acceso a datos del negocio.
• Aumentar el uso de tecnologías nativas de la nube y servicios administrados por AWS.
• AWS Backup para volúmenes de Amazon EFS

Lecciones Aprendidas

La lección más importante aprendida en el proyecto fue en torno a las pruebas, que terminaron siendo la parte del proyecto que más tiempo consumió y que más se subestima (70-80 por ciento del tiempo).

Los casos de prueba deben ser lo suficientemente granulares y automatizados.

Con el mainframe en funcionamiento durante más de 35 años, la aplicación COBOL había acumulado una buena cantidad de código obsoleto debido a la falta de mantenimiento adecuado. Es una buena práctica identificar este código y eliminarlo, lo que reduce la cantidad de trabajo de refactorización y prueba que se debe realizar.

Los mainframes suelen ser sistemas de procesamiento backend para otros servidores. Aristo generó diariamente más de 3.500 feeds de archivos de datos e informes para los consumidores intermedios. Tener un buen inventario de todos los consumidores e interfaces facilita la modernización y armonización de las comunicaciones.

Para el mantenimiento del código Java o el desarrollo de nuevas características, es una buena práctica entrenar a los desarrolladores COBOL de mainframe en lenguaje Java. Esto les permite proporcionar información funcional y conocimiento sobre estándares de códigos específicos para la aplicación, como convenciones de nomenclatura o estructura de código general.

Es importante obtener una comprensión profunda de la aplicación durante la fase de análisis y planificación para definir los paquetes de trabajo, identificar cuales tienen aproximadamente el mismo tamaño y complejidad y permiten reutilizar los aprendizajes para los paquetes posteriores. Por ejemplo, es bueno comenzar con la migración de los trabajos por lotes que a menudo son de alta complejidad y exigentes.

Si The New York Times ya tuviera su estrategia en la nube antes de comenzar la migración del mainframe, la compañía habría elegido migrar el mainframe directamente a AWS, evitando el trabajo adicional para diseñar e implementar el despliegue local de Aristo.

Beneficios del Proyecto para The New York Times

Si bien el proyecto de modernización comenzó como un ejercicio de reducción de costos, finalmente The New York Times dio pasos metódicos e incrementales hacia una adopción de tecnología más avanzada. Todo esto se hizo en un esfuerzo por mejorar el servicio al cliente y obtener una ventaja competitiva en una industria única que ha visto cambios significativos en la dinámica del mercado desde que el proyecto comenzó en 2015.

Este proyecto permitió la convergencia en un stack de tecnología común (Java y Oracle en AWS) uniéndose a la Plataforma de Suscripción Digital que ahora es ejecutada, construida y mantenida por el mismo grupo de Plataformas de Suscripción dentro de la organización de Tecnología del New York Times.

El equipo está acelerando la forma en que crea software en la nueva plataforma al adoptar una metodología ágil y un pipeline de CI / CD. Además, ahora hay un acceso más fácil a los datos para obtener información comercial y tecnológica, y un uso más rápido de las tecnologías nativas de la nube.

Aristo se lanzó el 28 de agosto de 2017. Durante el primer año, facturó más de medio billón de dólares en ingresos por suscripción, procesó casi 6.5 millones de transacciones y continuó enviando el periódico a los suscriptores de entrega a domicilio de The New York Times en Estados Unidos.

Sorprendentemente, Aristo hoy cuesta un 70 por ciento menos de operación por año que lo que funcionó en el mainframe en 2015, lo que le da al New York Times un importante ahorro de costos.

Modern Systems – APN Partner

Modern Systems es un socio tecnológico de APN Select. Son una empresa de modernización de sistemas legados con experiencia comprobada en todas las áreas de código legado y migración de datos, infraestructura, operaciones, monitoreo y mantenimiento, tanto durante como después de la transición.

Contacto Modern Systems | Resumen de la Solución | Comprar en Marketplace

*¿Ya trabajó con Modern Systems? Califique este Socio

* Para revisar un APN Partner, debe ser un cliente de AWS que haya trabajado con ellos directamente en un proyecto.

Revisores técnicos – idioma local

João Aragão Pereira

FSI Solution Architect, Amazon Web Services

Javier Cristancho

Solutions Architect, Amazon Web Services