Refatoração automatizada de um mainframe do New York Times para a AWS com Modern Systems

Por Michael Buzzetti, Engenheiro Chefe do The New York Times
Barry Tait, Diretor de Modernização e Estratégias de Nuvem na Modern Systems
Phil de Valence, arquiteto de soluções para modernização de mainframe na AWS

O New York Times tinha uma carga de trabalho crítica de negócios em execução em um mainframe como o principal sistema de TI, dando suporte à sua Plataforma de Entrega Diária.

Eles trabalharam com a Modern Systems, uma AWS Partner Network (APN) Select Technology, para transformar com sucesso seu aplicativo COBOL legado em um aplicativo moderno baseado em Java, executado na Amazon Web hoje Serviços (AWS).

Através de refatoração automatizada inovadora, o aplicativo foi modernizado para código orientado a objetos, e os dados foram transformados de arquivos indexados legados para um banco de dados relacional.

Esta publicação descreve o projeto, incluindo o processo de refatoração automatizada e a arquitetura da AWS, bem como lições aprendidas, resultados de negócios e planos tecnológicos futuros.

O contexto e os objetivos do New York Times

The New York Times é um jornal americano com influência e leitores em todo o mundo. Fundado em 1851, o jornal ganhou 125 Prêmios Pulitzer, mais do que qualquer outro jornal. O Times ocupa o 17º lugar no mundo por circulação e segundo nos Estados Unidos.

A principal aplicação da empresa gerencia diariamente a entrega ao domicílio do jornal desde 1979, apoiando uma linha de negócios no valor de mais de US $500 milhões por ano. Representou anos de experiência e conhecimento acumulados e, no entanto, foi significativamente resistente à sua modificação e evolução.

Além disso, o mainframe Z da IBM, executando o sistema operacional z/OS, era dispendioso de operar em comparação com as plataformas mais modernas que haviam evoluído na empresa. Ele precisava de um processo de modernização que reduzisse os custos operacionais e possibilitasse a convergência para uma Plataforma Digital com a Plataforma de Entrega ao Domicílio.

Entre 2006 e 2009, eles tiveram uma tentativa falha de reescrever manualmente o pedido de entrega ao domicílio. Em 2015, uma avaliação de abordagens alternativas determinou que uma segunda tentativa de redesenvolver o aplicativo teria sido muito mais cara, e uma alternativa para fazer uma rehospedagem emulada teria bloqueado dados sobre somente uma tecnologia proprietária.

Com a crescente pressão para reduzir rapidamente os custos, a estratégia escolhida foi migrar e converter código e dados com refatoração automatizada. Esta abordagem prometeu equivalência funcional, menor custo operacional e fácil integração com tecnologias modernas.

Origem da carga de trabalho do Mainframe

O aplicativo de mainframe chamado CIS no mainframe e renomeado Aristo após a migração, executava recursos críticos para os negócios, como faturamento, contas de clientes, roteamento de entrega, catálogo de produtos, preços e relatórios financeiros.

CIS era um aplicativo CICS/COBOL baseado em z/OS com uma interface 3270 baseada em BMS para acessar dados de negócios VSAM KSDS. Processamento batch era suportado por tarefas JCL com CA7 para agendamento de tarefas.

Em 2015, o CIS tinha crescido para mais de 2 milhões de linhas de código COBOL, 600 processos batch e 3.500 arquivos enviados diariamente para consumidores e sistemas. Foram utilizados cerca de 3 TB de dados ativos, compostos por 2 TB de arquivos VSAM e 1 TB de arquivos QSAM sequenciais. Usado 20 TB de backup de armazenamento frio.

Conversão automatizada com refatoração

O New York Times selecionou uma abordagem de conversão automatizada, que mantém a equivalência funcional e a lógica crítica de negócios, transformando aplicativos principais legados em aplicativos de linguagem Java orientados a objetos, tornando-os refatoráveis e manuteníveis. O código é analisado durante a avaliação para determinar como ele está preparado para ser migrado para a nuvem e o esforço necessário para obter o nível desejado de elasticidade (ou seja, escalabilidade horizontal e escalabilidade vertical) exigido pelas cargas de trabalho do aplicativo.

A solução de software Cobol-to-Universal Solution (CTU) da Modern Systems suporta componentes típicos de aplicativos COBOL baseados em mainframe, incluindo CICS, JCL e utilitários comuns, como IDCAMS e SORT, bem como repositório de dados como DB2 para z/OS, bancos de dados IMS, VSAM e IDMS.

O New York Times usou à solução CTU e seguiu uma metodologia de oito passos:

Figura 1 — Etapas de refatoração automatizada.

• Etapa 1: um inventário automatizado do mainframe é realizado, completando um repositório de componentes a serem migrados.
• Etapa 2: consiste em uma análise detalhada de aplicativos, modelo de dados, preferências de arquitetura, estilos de programação, conexões de banco de dados, manipulação de erros e opções de refatoração. Tudo isso leva à definição de como fragmentar a transformação de código com pacotes de trabalho e a estratégia de teste geral.
• Etapa 3: para cada pacote de trabalho, o modelo de dados é definido e criado no banco de dados de destino.
• Etapa 4: gera automaticamente programas e processos para baixar, transformar, validar e carregar dados do repositório de dados de origem para o banco de dados de destino.
• Etapa 5: a solução CTU da Modern Systems é usada para engenharia reversa do código COBOL em uma linguagem intermediária e, em seguida, para executar a engenharia direta para o código Java alvo.
• Etapa 6: executa testes de regressão para cada pacote de trabalho, garantindo que haja uma equivalência funcional entre os programas de mainframe de origem e o novo código Java.
• Etapa 7: é o processo de execução do teste de aceitação do usuário.
• Etapa 8: uma vez que esses testes são bem-sucedidos, a transição para a produção ocorre.

Usando Modern Systems CTU, o aplicativo Java resultante é orientado a objetos e separado em três camadas: lógica de apresentação, lógica de negócios e acesso a dados.

Para manter a mesma experiência do usuário, os mapas CICS BMS foram migrados para páginas web equivalentes que mimetizam às telas 3270 originais. Cada programa COBOL tornou-se uma classe Java, e JCL tornou-se JSR-352 XML usando o runtime Spring Batch para Java. Os arquivos VSAM KSDS foram migrados para um banco de dados relacional Oracle. Durante o processo de refatoração, todos os registros VSAM foram analisados e um DDL foi gerado para cada um dos layouts escolhidos.

A tabela na Figura 2 mostra o mapeamento de tecnologia entre o stack do mainframe legado e o stack da AWS de destino.

Figura 2 — Mapeamento da tecnologia de origem e destino.

Os componentes de substituição foram desenvolvidos em situações em que as dependências de aplicativos legados não eram compatíveis com o conjunto de ferramentas Modern Systems (por exemplo, REXX, GVEXPORT), quando pacotes de software padrão não estavam disponíveis como substituto, ou se fazia mais sentido usar os recursos do novo ambiente (backups do banco de dados do fornecedor e pontos de restauração, instantâneos do sistema de arquivos, etc.).

Teste de equivalência funcional

Era fundamental ter equivalência funcional entre o aplicativo Java e o aplicativo COBOL. Os grupos de componentes reuniram elementos relacionados que seriam executáveis e verificáveis juntos como uma única entidade por meio de interfaces de acesso externas, como serviços Web, telas de interface do usuário, tabelas de banco de dados e arquivos.

Os testes representaram aproximadamente 70-80% do tempo gasto no projeto. O processo de teste foi dividido em etapas, com cada etapa aumentando progressivamente em escopo e nível de dificuldade o isolamento da causa raiz das falhas dos testes.

• Estágio 1 – Teste de pré-entrega: Realizado pela Modern Systems antes de entregar o código refatorado.
• Estágio 2 – Validação da migração de dados: Verifique se os dados são os mesmos entre o VSAM de origem e o banco de dados relacional de destino.
• Estágio 3 – Teste do grupo de componentes: Verifique o comportamento funcional com um trabalho batch, uma ou mais telas, uma chamada de serviço Web.
• Estágio 4 – Teste de Regressão do Processamento batch: Use dados de teste estático (exatamente os mesmos dados de teste todos os dias) para verificar o processo de lote de ponta-a-ponta e realizar testes de regressão.
• Estágio 5 – Teste de Comparação de Processamento batch: Usando dados de teste dinâmico para verificar o batch de ponta-a-ponta com os dados atuais do dia, e comparar a saída entre sistemas legados e sistemas modernizados.
• Estágio 6 – Teste de Desempenho do Processamento batch: Usando dados de produção.
• Estágio 7 – Integração do sistema: Isso foi feito em colaboração com outras equipes e sistemas dentro da organização. Novas transações são inseridas através de sistemas de clientes, processadas em batch e fluxo para consumidores intermediários através de relatórios e feeds de arquivos.

Para estas etapas, a cobertura do teste deve ser ampla e profunda. Pode ser muito lento e complexo criar casos de teste, especialmente para trabalhos batch. A automação foi fundamental para lançar e analisar casos de teste repetidos e rápidos.

Arquitetura AWS alvo

À medida que o projeto avançou, o The New York Times contou com sua estratégia geral de data center para tornar a nuvem o ambiente de implantação preferido. Após menos de 1 ano de execução em um data center privado, Aristo foi migrado para a AWS. A equipe tinha obtido uma visão significativa sobre como era uma migração bem-sucedida, permitindo uma migração para a AWS com impacto mínimo nos negócios.

Figura 3 — Destino Aristo AWS Architecture Components.

Como mostrado na Figura 3, uma vez migrado para a AWS, o sistema foi dividido em quatro componentes principais:

• O sistema Front-End fornece aos operadores internos a capacidade de gerenciar assinaturas de entrega em domicílio.
• O sistema API fornece serviços web SOAP para outros sistemas.
• O sistema de relatórios cria relatórios para o departamento financeiro.
• Batch é o principal sistema onde todos os trabalhos noturnos são executados. Os trabalhos podem ser executados em qualquer instância, e a origem e o destino dos dados do trabalho são armazenados no Amazon Elastic File System (Amazon EFS)

Para acelerar a entrega da versão, foi criado um CI/CD (Continuous Delivery Pipeline, Integration Contínua and Continuous Delivery Pipeline) que inclui:

• Gradle para a construção e embalagem de artefatos.
• Artifactory para armazenamento e promoção de artefatos.
• Jenkins para implantação e orquestração.
• Ansible para gerenciamento de configuração.
• HashiCorp Vault para gerenciar tokens de acesso, chaves.

Linha do tempo de migração

A transformação do aplicativo que impulsiona a plataforma de entrega ao domicílio começou em 2015. Foi um processo de duas fases.

Refatoração automatizada

Esta fase durou cerca de 2 anos e incluiu tanto a transformação do COBOL em Java quanto a conversão do banco de dados VSAM para relacional, resultando no lançamento do aplicativo Aristo na produção local.

No final desta fase, o The New York Times anunciou sua estratégia de nuvem que impacta o futuro da plataforma Aristo e desencadeia a próxima fase.

Migração e melhorias da AWS

Uma vez que o aplicativo foi testado e estabilizado, o trabalho começou em agosto de 2017 para mover o aplicativo para a nuvem da AWS. Este foi um projeto de 8 meses, que também incluiu as seguintes alterações:

• Oracle RAC para Oracle EE
• Isilon para EFS.
• Atualizando Control-M da versão 7 para 8.
• Atualizando de FTP para SFTP/S3.
• Reconstrução do Pipeline I/CD (de Puppet to Ansible)

Figura 4 — Linha do tempo de migração de mainframe para a AWS.

Uma vez em produção na AWS em março de 2018, a Aristo se beneficiou de manutenção e melhorias, incluindo promoção de código, expansão de tabela, Entrega Domiciliar premium (HD) com novas ofertas de papel e digitais e otimizações de custos da AWS.

Olhando para o futuro, o The New York Times se concentra nessas melhorias futuras:

• Quebrar à aplicação monolítica em microsserviços.
• Convergência contínua dos recursos da plataforma de assinatura digital, incluindo pagamentos, catálogo de produtos, contas de clientes, contabilidade financeira.
• Desenvolvimento de novos serviços baseados em Java juntamente com código convertido.
• Facilitar o acesso aos dados empresariais.
• Aumentar o uso de tecnologias e serviços nativos da nuvem gerenciados pela AWS.
• Usar o Serviço AWS Backup para volumes do Amazon EFS.

Lições aprendidas

A lição mais importante aprendida no projeto foi sobre testes, que acabaram sendo a parte mais demorada e subestimada do projeto (70-80% do tempo).

Os casos de teste devem ser suficientemente granulares e automatizados.

Com o mainframe em operação há mais de 35 anos, o aplicativo COBOL acumulou uma boa quantidade de código obsoleto devido à falta de manutenção adequada. É uma boa prática identificar este código e removê-lo, o que reduz a quantidade de refatoração e trabalho de teste que precisa ser feito.

Normalmente, os mainframes são sistemas de processamento de back-end para outros servidores. Aristo gerou mais de 3.500 feeds de arquivos de dados e relatórios diariamente para consumidores intermediários. Ter um bom inventário de todos os consumidores e interfaces facilita a modernização e a harmonização das comunicações.

Para manter código Java ou desenvolver novos recursos, é uma boa prática para treinar desenvolvedores COBOL mainframe em linguagem Java. Isso permite que eles forneçam informações funcionais e conhecimentos sobre padrões de código específicos do aplicativo, como convenções de nomenclatura ou estrutura geral de código.

É importante obter uma compreensão profunda do aplicativo durante a fase de análise e planejamento para definir os pacotes de trabalho, identificar quais são aproximadamente o mesmo tamanho e complexidade e permitir que você reutilize os tutoriais para pacotes subseqüentes. Por exemplo, é bom começar com a migração de processos batch que muitas vezes são altamente complexos e exigentes.

Se o The New York Times tivesse sua estratégia de nuvem antes de iniciar a migração de mainframe, a empresa teria optado por migrar o mainframe diretamente para a AWS, evitando o trabalho extra para projetar e implementar a implantação local do Aristo.

Benefícios do Projeto para o The New York Times

Enquanto o projeto de modernização começou como um exercício de redução de custos, o New York Times eventualmente tomou medidas metódicas e incrementais para adotar tecnologias mais avançadas. Tudo isso foi feito em um esforço para melhorar o atendimento ao cliente e ganhar uma vantagem competitiva em uma única indústria que tem visto mudanças significativas na dinâmica do mercado desde que o projeto começou em 2015.

Esse projeto permitiu a convergência em um stack de tecnologia comum (Java e Oracle na AWS) ingressando na plataforma de assinatura digital que agora é executada, criada e mantida pelo mesmo grupo de plataformas de assinatura dentro da organização New York Times Technology.

A equipe está acelerando a forma como cria software na nova plataforma adotando uma metodologia ágil e um pipeline CI/CD. Além disso, agora há acesso mais fácil aos dados para informações comerciais e tecnológicas e uso mais rápido de tecnologias nativas da nuvem.

Aristo foi lançado em 28 de agosto de 2017. Durante o primeiro ano, ele faturou mais de meio trilhão de dólares em receita de assinatura, processou quase 6,5 milhões de transações, e continuou a enviar o jornal para assinantes de entrega domiciliar do The New York Times nos Estados Unidos.

Surpreendentemente, o Aristo hoje custa 70% menos operação por ano do que o que funcionou no mainframe em 2015, dando ao New York Times economias significativas de custos.

Modern Systems — Parceiro APN Spotlight

A Modern Systems é um parceiro de tecnologia da APN Select. É uma empresa de modernização de sistemas legados com experiência comprovada em todas as áreas de migração de código legado e dados, infraestrutura, operações, monitoramento e manutenção, durante e após a transição.

Entre em contato com a Modern Systems | Resumo da solução | Comprar no Marketplace

* Já trabalhou com Modern Systems? Classifique este parceiro

* Para analisar um parceiro da APN, você deve ser um cliente da AWS que trabalhou com ele diretamente em um projeto.

Revisores técnicos – idioma local

João Paulo Aragão Pereira

Arquiteto de soluções especialista na Indústria de Serviços Financeiros em LATAM, Amazon Web Services, trabalha com temas como modernização de sistemas legados como mainframe, detecção de fraude e vida em sistemas de pagamentos.

Erico Penna

Arquiteto de soluções para Parceiros em LATAM, Amazon Web Services, especialista em migrações, apaixonado por compartilhar conhecimentos e experiências, atuando como facilitador de migrações e modernização de aplicações para nuvem.