Como decompor um mainframe para microsserviços da AWS com a Blu Age

Por Alexis Henry, diretor de tecnologia da Blu Age

Os mainframes cresceram ao longo dos anos com uma complexidade impressionante. Eles costumam misturar diferentes linguagens, com milhões de linhas de código e padrões de codificação, repositórios de dados com várias interfaces, além de ter processamento online e batch.

Com o Amazon Web Services (AWS), os clientes usam microsserviços para agilidade, elasticidade e tecnologia de nuvem paga conforme o uso.

Nesta postagem, descrevemos as soluções Blu Age para decompor um mainframe com característica monolítica em microsserviços da AWS, e como resolver os desafios de dados associados à essa migração.

O Blu Age é um parceiro de tecnologia avançada da AWS Partner Network (APN). Nossas soluções são adequadas para decompor um mainframe em uma solução híbrida, e para migrar de forma incremental apenas partes das cargas de trabalho, do mainframe para a AWS.

Padrões de Decomposição do Mainframe

Decompor um mainframe em microsserviços pode ser desafiador, porque a plataforma de origem e as linguagens de programação associadas não são orientadas a serviços ou a objetos. Também não promovem o compartilhamento de dados externos e a chamada de procedimentos remotos com facilidade.

Os mainframes monolíticos acumularam milhões de linhas de código com diversos estilos e padrões de programação. Isso significa que a análise automatizada de código e os recursos de transformação associados são críticos para o sucesso. Eles permitem acomodar rapidamente as principais diferenças entre a arquitetura de mainframe e as plataformas distribuídas.

Para entregar projetos de decomposição de mainframe, as soluções Blu Age permitem três padrões diferentes através do uso da tecnologia Blu Age Analyzer, listados abaixo. Dependendo da carga de trabalho ou do tamanho e complexidade do monólito, um ou vários padrões podem ser combinados para cobrir a maioria das situações.

O Blu Age Analyzer foi projetado especificamente para identificar cada padrão e criar uma estratégia geral para decompor qualquer aplicativo monolítico.

Decompor com serviços de dados independentes

Esse é um padrão favorável em que o serviço extraído e o monólito têm dependências de dados independentes. Os programas são agrupados em um domínio, formando os limites do microsserviço. Os limites do domínio são definidos em torno de interfaces de baixo acoplamento, como transferência de arquivos, enfileiramento de mensagens, relatórios e consultas de inteligência de negócios.

O modelo de dados é estritamente consistente em cada domínio, no repositório de dados monolítico restante e no repositório de dados de microsserviço. Um microsserviço independente de dados é extraído e movido para a AWS.

Figura 1 – Decompor com serviços independentes de dados

Decompor com Consistência Eventual de Dados

Este é um padrão em que existem dependências de dados entre o serviço extraído e o monólito. Os dados são replicados entre o mainframe e a AWS. Isso evita a latência ou instabilidade da rede, o que seria incontrolável para típicos programas de I/O intensivo, como batch, ou prejudicial para transações de back-end online de alto rendimento.

Um serviço dependente de dados é extraído e movido para a AWS, e os dados dependentes são replicados de forma assíncrona nos dois sentidos em tempo real. Devido à replicação assíncrona bidirecional, há consistência eventual dos dados. Para resolução de conflitos, com base na análise da carga de trabalho e nos tipos de acesso, estratégias como “mainframe-as-a-reference “ou “Last Write Win” podem ser adotadas.

Figura 2 – Decompor com consistência eventual dos dados

Agrupe e decomponha com consistência estrita de dados

Quando há muitas dependências de gravação ou fortes requisitos nas transações, a consistência eventual pode se tornar um desafio. Nesse padrão, grupos de programas e suas dependências de dados são movidos completamente para preservar a consistência estrita.

Os programas dependentes de dados são agrupados em grupos independentes de dados. Um grupo independente de dados é extraído e movido para os microsserviços da AWS com um armazenamento de dados compartilhado. Eventualmente, microsserviços individuais podem se beneficiar de uma pilha de implantação ou armazenamento de dados separado.

Figura 3 – Agrupe e decomponha com consistência estrita de dados

Decompondo em microsserviços com o Blu Age Analyzer

Uma arquitetura de microsserviços decompõe aplicativos em domínios de negócios fracamente acoplados. A ideia é que qualquer equipe responsável por um domínio possa alterar a maneira como as coisas são feitas dentro do domínio sem afetar os outros domínios de aplicativo com os quais interage. Ao decompor um monólito, é necessário identificar os vários domínios e limites associados.

O Blu Age Analyzer conta com os padrões anteriores para definir a decomposição dos microsserviços. Posteriormente, o Blu Age Velocity automatiza a refatoração da modernização.

Agora, descreveremos as etapas executadas com o Blu Age Analyzer para identificar domínios de microsserviços.

Etapa 1: Análise Vertical

O Blu Age Analyzer identifica automaticamente todos os pontos de entrada no sistema e organiza as dependências em anéis concêntricos. Os microsserviços aparecem como árvores locais a partir do exterior. Nesta fase, ainda existem alguns elementos de acoplamento que aparecem nas camadas internas identificadas pela zona verde na Figura 4. Este estágio de análise é totalmente automatizado.

Figura 4 – Análise vertical do Blu Age Analyzer

Etapa 2: Definição de domínios de negócios

Durante esta etapa, as dependências dos programas principais são resolvidas e os limites individuais do domínio são finalizados. Isso leva a uma colaboração starfish, onde poucos domínios centrais (programas com muito pouco código) contêm programas utilitários e domínios satélites contêm a lógica de negócios. Os domínios satélites usam domínios centrais e colaboram diretamente com outros domínios satélite.

Figura 5 – Definição detalhada de domínio do Blu Age Analyzer

A decomposição do domínio e a detecção de limites são feitas analisando os relacionamentos de requisitante/requisitado, tipo de acesso a dados e formatos de dados. O exemplo na Figura 6 mostra para uma determinada árvore de programas, as dependências de dados de acordo com seus formatos de dados. Ele destaca o VSAM (Virtual Storage Access Method) e os tipos de acesso do DB2.

Figura 6 – Tipos de acesso a dados do Blu Age Analyzer

Nesse estágio, um usuário do Blu Age Analyzer pode optar por alterar a definição dos limites. Normalmente, um usuário pode ajustar um domínio com base em aprimoramentos de negócios ou otimizar a composição da API e a sincronização de dados. Isso é comum na definição de microsserviços, onde os limites são otimizados por meio de iterações.

O Blu Age Analyzer facilita essa tarefa usando a anotação de tags. O esforço de ajuste de limites de domínio é tipicamente meio dia de trabalho de um profissional por milhão de linhas de código.

Etapa 3: Definição de domínios utilitários

Os usuários devem decidir incluir os domínios do utilitário central como bibliotecas em microsserviços ou como microsserviços eles mesmos. Esses domínios centrais geralmente se tornam bibliotecas, pois geralmente não fazem I/O e contêm apenas programas utilitários, que provavelmente seriam substituídos por estruturas prontas para uso, quando modernizadas.

A Figura 7 mostra a decomposição final com conexões entre domínios com uma única seta laranja por colaboração de domínio.

Figura 7 – Decomposição final em microsserviços do Blu Age Analyzer

Design de Microsserviço Blu Age Velocity

O Blu Age Analyzer não apenas facilita a definição de domínios e microsserviços, mas também calcula e dirige as opções da refatoração. O Blu Age Velocity usa todas essas opções de transformação como entradas. Ele executa a refatoração automatizada da pilha de software completa (código, dados, acesso a dados, acesso a dependências, estruturas) em uma pilha de destino pré-selecionada baseado em Java, AngularJS, SpringBoot, Spring Statemachine e REST APIs.

Figura 8 – Diagrama de microsserviço Blu Age Velocity

O BluSAM Server atua como um contêiner de microsserviço e tem flexibilidade para ser implantado em vários serviços de computação da AWS. Também pode acessar dados de vários serviços de dados, como o Amazon Aurora ou o Amazon ElastiCache. Velocity e BluSAM permitem implementar os padrões de decomposição do mainframe, bem como os padrões de banco de dados descritos nesta publicação.

Saiba mais sobre a arquitetura Velocity e BluSAM na AWS nesta postagem do blog da APN.

Padrões de banco de dados – Prós e contras

Uma decisão importante a ser tomada ao projetar microsserviços é escolher o padrão do banco de dados com base nos requisitos de consistência dos dados. Sistemas financeiros, por exemplo, exigem uma consistência mais forte. Outros sistemas podem aceitar consistência eventual, favorecendo desempenho, menor acoplamento e eficiência nos negócios.

A tabela a seguir detalha qual suporte de consistência está associado aos padrões de decomposição e banco de dados.

Figura 9 – Consistência e suporte à transação por padrão de decomposição

Consistência rigorosa e suporte a transações ACID (atomicidade, consistência, isolamento, durabilidade) fornecem operação automática roll-back em caso de falha. É realizada de forma transparente pelos servidores de banco de dados e de transações para o aplicativo.

Por outro lado, a consistência eventual não pode usar esse recurso de transação e requer códigos ou mecanismos adicionais de aplicativo para gerenciar falhas. Por exemplo, com composição de API, o padrão Try-Cancel / Confirm (TCC) ou o padrão Saga podem ser implementados para corrigir falhas. Com a sincronização de dados, estratégias de replicação e re-tentativa e resolução de conflitos podem ser implementadas.

O padrão de Banco de Dados Compartilhado preserva consistência estrita e suporte a transações. Portanto, é atraente ao fazer a transição do mainframe para a AWS no modo híbrido. Isso minimiza a necessidade de alterações manuais do código e aproveita bem a automação da refatoração, motivo pelo qual muitas vezes os riscos são menores ao primeiro usar o padrão de banco de dados compartilhado e depois passar a usar o banco de dados por padrão de domínio, se necessário.

Os padrões de banco de dados por domínio requerem limites explícitos de domínio. Normalmente, eles são definidos iterativamente com refatoração manual complexa até que os limites sejam eventualmente estáveis. Normalmente, o padrão de sincronização de dados é preferível à composição de API, pois fornece melhor desempenho, agilidade e acomoda batches de carga de trabalho do mainframe.

Arquitetura de replicação de dados

Em muitos casos, os padrões de Dados Independentes ou Banco de Dados Compartilhado são escolhidos por manter uma consistência estrita e permitir que o banco de dados gerencie falhas ou a recuperação de transações. Isso significa que os padrões “Decompor com serviços independentes de dados ” e “Agrupar e decompor com consistência estrita de dados” são escolhidos e nenhuma replicação de dados é necessária.

Nos casos em que o padrão “Decompor com consistência eventual de dados” é escolhido, o padrão Banco de Dados por Domínio não permite que um domínio acesse diretamente os dados de outro domínio. Portanto, os usuários devem manter alguns dados em cada banco de dados do domínio sincronizados.

A Figura 10 mostra a abordagem geral para consumir microsserviços enquanto sincroniza dados compartilhados duplicados. Os microsserviços são implantados independentemente com seu próprio banco de dados e os serviços são expostos como REST API para fazer a composição da API. Normalmente, os usuários podem usar o AWS API Gateway para consumir serviços REST e fazer a composição.

Nenhuma API de atualização de dados é exposta para executar a sincronização de dados, e a replicação de dados é obtida intrinsicamente usando o Change Data Capture (CDC) e a Propagação de Eventos.

CDC: uma alteração de estado de dados é identificada no banco de dados de origem e aciona uma ação que permite que a arquitetura distribuída sincronize os dados na sequência correta.
Propagação de Eventos de Dados: O mecanismo de replicação ou o broker de eventos distribuídos transporta dados do CDC para todos os bancos de dados de destino. Ele deve garantir a entrega de mensagens, o dimensionamento automático, o registro no diário de mensagens (persistência) e o sequenciamento de mensagens.

Figura 10 – Replicação de dados utilizando CDC e manipulação de eventos

Para a replicação de dados do mainframe para AWS, existem vários pacotes de soluções de fornecedores disponíveis para replicação de dados assíncrona em tempo real baseada em CDC. Eles geralmente oferecem suporte a repositórios de dados de mainframe relacionais, hierárquicos e baseados em arquivos e replicam dados para repositórios de dados da AWS, como Amazon Relational Database Service (Amazon RDS), Amazon Aurora ou Amazon Kinesis.

Dependendo dos requisitos específicos, várias soluções ou componentes podem ser combinados para atingir o destino desejado, como o Amazon DynamoDB, ou para atender aos requisitos da qualidade de serviço.

Para replicação de dados da AWS para o mainframe, as soluções de fornecedores em pacotes podem ser usadas a partir de repositórios de dados da AWS para repositórios de dados legados do mainframe. Além disso, os serviços nativos da AWS podem ser usados para alavancar gatilhos para o CDC, serviços de mensagens como Amazon Simple Queue Service (Amazon SQS), Amazon MQ e Amazon Kinesis para invocações assíncronas e drivers nativos de mainframe para atualizar repositórios de dados herdados.

Para replicação de dados da AWS para a AWS, quando pelo menos 2 microsserviços são implantados na AWS, os serviços gerenciados nativos da AWS podem ser usados, alavancando gatilhos e serviços de mensagens.

Próximas etapas

Esta publicação focou em como decompor um mainframe monolítico em microsserviços, e como lidar com dependências de dados, especialmente com o banco de dados por padrão de domínio. Para saber mais sobre microsserviços, domínios e contexto limitado, consulte os seguintes artigos:

Se você gostaria de aprender sobre uma carga de trabalho de mainframe refatorada ou sobre arquitetura de microsserviços na AWS, você deve ler “Como migrar cargas de trabalho Batch do Mainframe para Microsserviços na AWS com Blu Age”.

Para saber mais sobre a refatoração automática de código COBOL para a AWS (ou de qualquer linguagem de programação suportada pelo mainframe), consulte “Blu Genius para Mainframe com Transformação Nativa para a nuvem AWS”.

Para solicitar uma demonstração da decomposição de um mainframe monolítico com o Blu Age Analyzer e o Velocity, entre em contato conosco.

O conteúdo e as opiniões deste blog são de terceiros e a AWS não é responsável pelo conteúdo ou pela precisão desta postagem.

Blu Age – Parceiro da APN em destaque

Blu Age é um parceiro de tecnologia avançada APN. Sua tecnologia automatiza à transformação de aplicativos de negócios legados em

aplicativos digitais completos com os mais recentes padrões tecnológicos.

Entre em contato com Blu Age | Demonstração da solução | Comprar no Marketplace

* Já trabalhou com Blu Age? Classifique este parceiro

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

O blog da AWS