Modernização de mainframe e midrange com os Aplicativos Lógicos do Azure
Este guia descreve como sua organização pode aumentar o valor comercial e a agilidade modernizando seus ambientes de mainframe e midrange usando os Aplicativos Lógicos do Azure. O mundo dos negócios atual está passando por uma era de hiperinovação e está em uma busca permanente para obter eficiências empresariais, redução de custos, crescimento e alinhamento de negócios. As organizações estão procurando maneiras de se modernizar, e uma estratégia eficaz é aumentar o valor do negócio enquanto usa ativos legados existentes.
Para organizações com investimentos em mainframe e sistemas midrange, isso significa fazer o melhor uso de plataformas que ajudaram a enviar humanos para a lua ou ajudaram a construir os mercados financeiros atuais e ampliar seu valor usando a nuvem e a inteligência artificial (IA). Este cenário é onde os Aplicativos Lógicos do Azure e seus recursos nativos de integração com sistemas mainframe e midrange entram em jogo, abrindo as portas para o mundo da IA para investimentos legados. Entre outros recursos, os Aplicativos Lógicos do Azure incorporam os principais recursos do Host Integration Server (HIS), que tem sido usado para integração de mainframe e midrange no núcleo dos clientes mais estratégicos da Microsoft ao longo de 20+ anos. Como resultado, os Aplicativos Lógicos do Azure se tornaram uma plataforma de integração como serviço (iPaaS) para mainframe e sistemas midrange.
Quando os desenvolvedores corporativos criam fluxos de trabalho de integração com os Aplicativos Lógicos do Azure, eles podem entregar novos aplicativos mais rapidamente usando pouco ou nenhum código ou menos código personalizado. Os desenvolvedores que usam o Visual Studio Code e o Visual Studio podem ser mais produtivos do que aqueles que usam ferramentas e tecnologias de desenvolvimento de mainframe IBM porque não exigem conhecimento sobre sistemas e infraestrutura de mainframe. As Aplicações Lógicas do Azure permitem que os analistas empresariais e os decisores analisem e relatem mais rapidamente informações legadas vitais. Eles podem acessar dados diretamente em fontes de dados de mainframe, o que elimina a necessidade de que os desenvolvedores de mainframe criem programas que extraem e convertam estruturas complexas de mainframe.
Recursos nativos da nuvem para integração de mainframe e sistemas midrange
Desde 1990, a Microsoft fornece integração com sistemas mainframe e midrange através do Microsoft Communications Server. A evolução do Microsoft Communications Server criou o Host Integration Server (HIS) em 2000. Enquanto o HIS começou como um System Network Architecture (SNA) Gateway, o HIS expandiu-se para incluir armazenamentos de dados IBM (DB2, VSAM e Informix), sistemas de transação IBM (CICS, IMS e IBM i) e mensagens IBM (MQ Series). Os clientes estratégicos da Microsoft utilizam estas tecnologias há mais de 20 anos.
Para permitir que os clientes que executam aplicativos e dados no Azure continuem usando essas tecnologias, os Aplicativos Lógicos do Azure e o Visual Studio incorporaram gradualmente esses recursos. Por exemplo, o HIS Designer for Logic Apps que é executado no Visual Studio e a 3270 Design Tool ajudam a criar artefatos de metadados exigidos pelos conectores internos que você usa para integração de mainframe e midrange nos Aplicativos Lógicos do Azure. Esses conectores internos são executados usando os mesmos recursos de computação que os fluxos de trabalho do aplicativo lógico padrão. Esse design não só permite que você alcance cenários de baixa latência, mas também amplia seu alcance para atender a mais necessidades de clientes de recuperação de desastres e alta disponibilidade.
Para obter mais informações sobre os recursos da Microsoft para integração de mainframe e midrange, continue para as seções a seguir.
Microsoft HIS Designer para aplicativos lógicos
Essa ferramenta cria artefatos de metadados de mainframe e sistema midrange para Aplicativos Lógicos do Azure e funciona com o Microsoft Visual Studio fornecendo um designer gráfico para que você possa criar, exibir, editar e mapear objetos de metadados para artefatos de mainframe. Os Aplicativos Lógicos do Azure usam esses mapas para espelhar os programas e dados em sistemas de mainframe e midrange. Para obter mais informações, consulte HIS Designer for Logic Apps.
Ferramenta de design do Microsoft 3270
Essa ferramenta registra telas, caminhos de navegação, métodos e parâmetros para as tarefas em seu aplicativo para que você possa adicionar e executar essas tarefas como ações de conector 3270. Enquanto o HIS Designer for Logic Apps tem como alvo sistemas e dados transacionais, a 3270 Design Tool tem como alvo 3270 aplicativos. Para obter mais informações, consulte 3270 Design Tool.
Conectores do Azure Logic Apps para mainframe IBM e sistemas midrange
As seções a seguir descrevem os conectores internos baseados em provedor de serviços que você pode usar para acessar e interagir com sistemas de mainframe e midrange IBM ao criar fluxos de trabalho padrão em Aplicativos Lógicos do Azure.
Nota
Embora alguns dos conectores a seguir estejam disponíveis como conectores "compartilhados" executados no Azure global, este guia se concentra nos conectores internos baseados em provedor de serviços, que estão disponíveis somente quando você cria fluxos de trabalho padrão em Aplicativos Lógicos do Azure.
IBM 3270
Este conector de Aplicativos Lógicos do Azure para 3270 permite que fluxos de trabalho padrão acessem e executem aplicativos de mainframe IBM que você normalmente dirige navegando pelas telas do emulador 3270. O conector usa o fluxo TN3270. Para obter mais informações, consulte Integrar aplicativos controlados por tela 3270 em mainframes IBM com o Azure usando o Azure Logic Apps e o conector IBM 3270.
Sistema de Controle de Informações do Cliente IBM (CICS)
Este conector de Aplicativos Lógicos do Azure para CICS fornece fluxos de trabalho padrão com a capacidade de interagir e integrar com programas CICS usando vários protocolos, como TCP/IP e HTTP. Se você precisar acessar ambientes CICS usando LU6.2, precisará usar o Host Integration Server (HIS). Para obter mais informações, consulte Integrar programas CICS em mainframes IBM com fluxos de trabalho padrão em Aplicativos Lógicos do Azure usando o conector IBM CICS.
IBM DB2
Este conector de Aplicativos Lógicos do Azure para DB2 permite conexões entre fluxos de trabalho Standard e bancos de dados DB2 que estão no local ou no Azure. O conector oferece aos profissionais de TI corporativos e desenvolvedores acesso direto a informações vitais armazenadas nos sistemas de gerenciamento de banco de dados DB2. Para obter mais informações, consulte Acessar e gerenciar recursos do IBM DB2 usando o Azure Logic Apps.
Arquivos de host IBM
Este "conector" de Aplicativos Lógicos do Azure para Arquivos Host fornece um wrapper fino em torno do recurso "Flat File Parser" no Host Integration Server. Este "conector" offline fornece operações que analisam ou geram dados binários de e para arquivos host. Essas operações exigem que esses dados venham de qualquer gatilho ou outra ação que produza dados binários. Para obter mais informações, consulte Analisar e gerar arquivos de host IBM usando o Azure Logic Apps.
IBM i
Este conector de Aplicações Lógicas do Azure para IBM i permite que fluxos de trabalho Standard interajam e se integrem com programas COBOL e RPG em execução em sistemas IBM i utilizando TCP/IP. Se você precisar acessar ambientes IBM i usando LU6.2, precisará usar o Host Integration Server (HIS). Para obter mais informações, consulte Integrar programas COBOL e RPG em midranges IBM com fluxos de trabalho padrão em Aplicativos Lógicos do Azure usando o conector IBM i.
Sistema de Gerenciamento de Informações IBM (IMS)
Este conector de Aplicativos Lógicos do Azure para IMS usa o componente IBM IMS Connect, que fornece acesso de alto desempenho de fluxos de trabalho padrão para transações IMS usando TCP/IP. Este modelo usa a fila de mensagens IMS para processar dados. Para obter mais informações, consulte Integrar programas IMS em mainframes IBM com fluxos de trabalho padrão em Aplicativos Lógicos do Azure usando o conector IBM IMS.
IBM MQ
Este conector de Aplicativos Lógicos do Azure para MQ permite conexões entre fluxos de trabalho Standard e servidores IBM MQ no local ou no Azure. A Microsoft também fornece recursos de integração do IBM MQ com o Host Integration Server e o BizTalk Server. Para obter mais informações, consulte Conectar-se a um servidor IBM MQ a partir de um fluxo de trabalho no Azure Logic Apps.
Desafios para a modernização de sistemas mainframe e midrange
Os sistemas mainframe e midrange podem hospedar vários ambientes que contêm programas, dados, arquivos e ferramentas. Ao longo dos anos, esses ambientes podem não ter sido refatorados, ou foram deixados para crescer e atingir seus limites, apesar das atualizações de hardware. Esses ambientes também podem ter sido mantidos por vários desenvolvedores e administradores de TI, que seguem diferentes padrões e técnicas de programação, ou recrutaram outras partes para ajudar em tarefas que exigem experiência escassa no mercado. Juntamente com um grupo cada vez menor de profissionais experientes, todos esses fatores criam um trabalho complexo e desafiador de modernização de ambientes de mainframe e midrange.
Embora a lista a seguir não seja abrangente, a definição de uma estratégia de modernização bem-sucedida inclui minimamente maneiras de lidar com as seguintes tarefas:
- Mantenha os indicadores e objetivos de nível de serviço atuais para seus ambientes.
- Gerencie a coexistência entre dados herdados juntamente com dados migrados.
- Conduza DevOps entre ambientes durante a coexistência.
- Gerencie interdependências de aplicativos.
- Defina o futuro do agendador e dos trabalhos de mainframe.
- Definir uma estratégia para substituir produtos comerciais prontos a usar (COTS).
- Realizar atividades híbridas de testes funcionais e não funcionais.
- Manter dependências ou interfaces externas.
Com essas tarefas em mente, os clientes normalmente escolhem qualquer um dos seguintes caminhos para conduzir a modernização de sistemas mainframe e midrange:
Grande estrondo
Essa abordagem é amplamente baseada no modelo de entrega de software em cascata, mas com iterações em fases. A abordagem big bang é adotada mais por clientes com sistemas de mainframe ou midrange pequenos e ambientes de baixa complexidade devido a um baixo número de linhas de código, baixa densidade de aplicativos e sistemas legados ou linguagens de programação bem conhecidos.
Ondas ágeis
Esta abordagem segue os princípios ágeis da engenharia de software. A abordagem de ondas ágeis é adotada mais por clientes com sistemas mainframe ou midrange maiores e ambientes de alta complexidade devido a um alto número de linhas de código, alta densidade de aplicativos, sistemas ou linguagens de programação menos conhecidos e um alto número de dependências e interfaces.
A escolha entre esses caminhos depende das necessidades e dos cenários da sua organização. Cada caminho tem benefícios e desvantagens a considerar. As seções a seguir fornecem mais informações sobre essas abordagens de modernização.
Big bang ou cachoeira
Uma migração de big bang normalmente tem as seguintes fases:
Previsão: Kickoff
Planejamento: identifique e prepare as entregas de planejamento, como escopo, tempo e recursos.
Construção: Começa depois que as entregas de planejamento são aprovadas
Esta fase também espera que todo o trabalho para as dependências tenha sido identificado e, em seguida, as atividades de migração possam começar. Várias iterações ocorrem para concluir o trabalho de migração.
Estabilização ou teste: começa quando o ambiente, as dependências e os aplicativos migrados são testados em relação às regiões de teste no ambiente de mainframe.
Implantação: depois que tudo for aprovado, a migração entrará em produção.
As organizações que normalmente escolhem essa abordagem se concentram no tempo de bloqueio, no escopo da migração e nos recursos. Este caminho parece uma escolha positiva, mas inclui os seguintes riscos:
As migrações podem levar meses ou até anos.
As implantações na produção são mais arriscadas.
A análise que você realiza no início da jornada de migração ou durante o planejamento não é mais precisa porque essas informações geralmente estão desatualizadas.
As organizações normalmente se concentram em ter documentação abrangente para reduzir os riscos de entrega para entrega.
No entanto, o tempo gasto no fornecimento de artefatos de planejamento causa exatamente o efeito oposto. Focar mais no planejamento do que na execução tende a gerar atrasos na execução, o que causa aumento de custos a longo prazo.
Ondas ágeis
Uma abordagem ágil é orientada para resultados e focada na construção de software e não no planejamento de entregas. Os primeiros estágios de uma entrega ágil podem ser caóticos e complexos para as barreiras organizacionais que precisam ser quebradas e alinhar a equipe de migração. No entanto, depois que a equipe de migração amadurece após vários sprints de execução, a jornada se torna mais suave. O objetivo dessa abordagem é lançar frequentemente recursos para a produção e fornecer valor comercial mais cedo do que com uma abordagem de big bang.
Uma migração de ondas ágeis normalmente tem os seguintes sprints:
Sprint zero (0)
- Defina a equipe, uma lista de pendências de trabalho inicial e as dependências principais.
- Identifique os recursos e um Produto Mínimo Viável (MVP) a ser entregue.
- Inicie a preparação do mainframe com um conjunto selecionado de itens de trabalho ou histórias de usuários para iniciar o trabalho.
Sprint 1, 2, ..., N
Cada sprint tem um objetivo onde a equipe mantém uma mentalidade de envio, o que significa que eles se concentram em completar as metas de migração e liberar entregas para a produção. A equipe pode usar um grupo de sprints para entregar um recurso específico ou uma onda de recursos. Cada recurso inclui fatias de cargas de trabalho de integração.
Elementos compartilhados, como empregos e interdependências, existem e têm impacto em todo o ambiente. Uma estratégia bem-sucedida se concentra em habilitar parcialmente empregos, redesenhar aplicativos para modernização e deixar os sistemas com a maioria das interdependências até o final para, primeiro, reduzir a quantidade de trabalho de migração e, em seguida, completar o escopo do esforço de modernização.
A Microsoft recomenda modernizar as cargas de trabalho de mainframe e sistemas midrange seguindo um modelo iterativo baseado em ondas ágeis, concentrando-se em investimentos na nova plataforma, enquanto limita o crescimento de sistemas legados. Essa abordagem reduz consideravelmente os riscos de implementação, preservando o valor comercial existente, ao mesmo tempo em que introduz o ambiente modernizado. Dessa forma, sua equipe também pode aproveitar as habilidades tecnológicas que ajudam sua empresa a ser mais competitiva. Este cenário é onde os Aplicativos Lógicos do Azure podem ajudá-lo em sua jornada de modernização.
Padrões de modernização
Um bom design inclui fatores como consistência e coerência no projeto e implantação de componentes, capacidade de manutenção para simplificar a administração e o desenvolvimento e capacidade de reutilização que permite que outros aplicativos e cenários reutilizem componentes e subsistemas. Para aplicativos e serviços hospedados na nuvem, as decisões tomadas durante a fase de projeto e implementação têm um enorme impacto na qualidade e no custo total de propriedade.
O Centro de Arquitetura do Azure fornece padrões de design e implementação testados que descrevem o problema que eles abordam, considerações para aplicar o padrão e um exemplo baseado no Microsoft Azure. Embora existam vários padrões de design e implementação, alguns dos padrões mais relevantes para a modernização do mainframe incluem os padrões "Anti-corruption Layer", "Strangler Fig", "Saga" e "Choreography".
Padrão de camada anticorrupção
Independentemente da abordagem de modernização selecionada, você precisa implementar uma "camada anticorrupção" usando os Aplicativos Lógicos do Azure. Esse serviço se torna a camada de fachada ou adaptador entre o sistema herdado de mainframe e o Azure. Para uma abordagem eficaz, identifique as cargas de trabalho de mainframe a serem integradas ou coexistirem como cargas de trabalho de integração de mainframe. Crie uma estratégia para cada carga de trabalho de integração, que é o conjunto de interfaces que você precisa habilitar para migrar um aplicativo de mainframe.
Para obter mais informações, consulte Camada anticorrupção.
Padrão de figo Strangler
Depois de implementar a camada anticorrupção, a modernização acontece progressivamente. Para esta fase, você precisa usar o padrão "Strangler Fig", onde você identifica cargas de trabalho de mainframe ou recursos que podem ser modernizados incrementalmente. Por exemplo, se você optar por modernizar um aplicativo CICS, terá que modernizar não apenas os programas CICS, mas provavelmente os aplicativos 3270, juntamente com suas dependências externas, dados e trabalhos correspondentes.
Eventualmente, depois de substituir todas as cargas de trabalho ou recursos no sistema de mainframe pelo novo sistema, você concluirá o processo de migração, o que significa que você pode encerrar seu sistema legado.
Para obter mais informações, consulte Strangler Fig pattern.
Padrões de Saga e Coreografia
As transações distribuídas, como o protocolo de confirmação bifásica (2PC), exigem que todos os participantes de uma transação confirmem ou revertam antes que a transação possa prosseguir. As arquiteturas híbridas em nuvem funcionam melhor seguindo um eventual paradigma de consistência em vez de um modelo de transação distribuída.
O padrão de design "Saga" é uma maneira de gerenciar a consistência entre serviços em cenários de transações distribuídas. Uma saga é uma sequência de transações que atualiza cada serviço e publica uma mensagem ou evento para acionar a próxima etapa da transação. Se uma etapa falhar, a saga executa transações de compensação que neutralizam as transações anteriores. Para obter mais informações, consulte Padrão de transações distribuídas Saga.
Nos Aplicativos Lógicos do Azure, os fluxos de trabalho podem atuar como coreógrafos para coordenar sagas. As ações do fluxo de trabalho são atômicas, para que você possa executá-las novamente individualmente. O tipo de ação Escopo fornece a capacidade de executar um grupo de ações somente depois que outro grupo de ações for bem-sucedido ou falhar. Os Aplicativos Lógicos do Azure realizam transações de compensação no nível do escopo, enquanto a Grade de Eventos do Azure e o Barramento de Serviço do Azure fornecem o gerenciamento de eventos necessário para domínios específicos. Todos esses serviços, que compõem o Azure Integration Services, fornecem o suporte exigido pelos clientes quando precisam de uma plataforma de integração confiável para cenários de missão crítica. Para obter mais informações, consulte Padrão coreográfico.
Embora este artigo abranja vários padrões de modernização, soluções complexas exigem muito mais padrões e que você entenda claramente as metas de modernização da sua organização. Embora a tarefa de ampliar o valor dos ativos legados seja desafiadora, essa opção é a melhor maneira de preservar o investimento nesses ativos e prolongar seu valor comercial.