Este artigo descreve uma abordagem de migração para reformular suas cargas de trabalho do AIX para a nuvem. Você pode usar o Azure Functions para uma arquitetura sem servidor ou usar as Máquinas Virtuais do Azure para manter um modelo com servidor.
Considere uma estratégia de migração de replataforma para cargas de trabalho AIX para maximizar seu retorno sobre o investimento (ROI) ao migrar aplicativos herdados para o Azure. As migrações de replataforma exigem alterações mínimas, mas oferecem benefícios nativos da nuvem semelhantes a uma migração de refatoramento.
Os benefícios de uma migração de replataforma incluem:
- Um custo total de propriedade (TCO) reduzido.
- Maior agilidade nos negócios.
- Maior resiliência operacional.
Arquitetura (replataforma)
Transfira um ficheiro do Visio desta arquitetura.
Fluxo de Trabalho
Este fluxo de trabalho corresponde à arquitetura anterior.
As solicitações de usuário e as integrações de API de entrada são transferidas para o Gateway de Aplicativo do Azure em TCP/443 (HTTPS), que fornece uma funcionalidade de firewall de aplicativo Web (WAF). O Application Gateway envia as solicitações, como solicitações de proxy reverso, para vários serviços hospedados no Red Hat JBoss Enterprise Application Platform (EAP).
Java Web Services interroga o banco de dados Oracle (TCP/1521). O tempo de resposta da solicitação da Web síncrona é inferior a 50 milissegundos (ms).
Uma solicitação assíncrona, como o agendamento de uma tarefa em lote, coloca um registro em uma tabela de banco de dados que atua como uma fila dentro da camada de aplicativo.
Nota
No futuro, o Armazenamento de Filas do Azure substituirá a tabela de banco de dados, para que você sempre possa ter acesso a trabalhos de análise em execução.
O trabalho cron, escrito em script KornShell (ksh), é portado para Bash e executado em um servidor Red Hat Enterprise Linux (RHEL) separado em Conjuntos de Escala de Máquina Virtual do Azure. O trabalho cron é executado a cada 15 minutos, inclusive na inicialização do sistema, para consultar a fila no banco de dados Oracle. Os trabalhos são executados um de cada vez por host. Os Conjuntos de Dimensionamento de Máquina Virtual paralelizam trabalhos de análise de longa duração. Esta solução não requer processamento em lote fora do horário de pico para limitar o efeito no desempenho do sistema durante o horário comercial.
Os Serviços de Comunicação do Azure enviam alertas por email por meio da ferramenta CLI do Azure (docs). As identidades gerenciadas atribuídas ao sistema do Azure, como
az login --identity, autenticam a máquina virtual (VM).Os resultados do trabalho de análise vão para um compartilhamento de Arquivos do Azure por meio do SMBv3 seguro (TCP/445), que também usa identidades gerenciadas atribuídas ao sistema.
Componentes
O Microsoft Entra ID elimina a confiança baseada em rede e fornece identidades gerenciadas atribuídas ao sistema, o que melhora a segurança.
O Serviço de Aplicativo do Azure elimina a necessidade de administrar um sistema operacional e um servidor, o que aumenta a eficiência operacional e a agilidade dos negócios.
O Application Gateway é um serviço totalmente gerenciado e escalável que fornece firewall de aplicativos Web e funcionalidade de proxy reverso.
Os Arquivos do Azure fornecem relatórios de dados que são publicados por meio de um serviço gerenciado.
O Azure Functions é uma plataforma de computação sem servidor orientada por eventos que é usada para desenvolver código de forma eficiente na linguagem de programação especificada.
Um de Máquinas Virtuais do
Azure é usado pelo banco de dados Oracle e pelos nós de análise SAS. A Galeria de Computação do Azure cria e armazena imagens para o banco de dados Oracle e os nós de análise SAS. Existem duas galerias: uma na região primária e outra na região de recuperação de desastres.
Os Serviços de Comunicação enviam e-mails com um utilitário CLI. Este serviço substitui o
mailxcomando no AIX.
Alternativas
Uma alternativa é uma arquitetura completa de servidor que mantém todos os componentes de middleware como estão.
Esta solução é semelhante à arquitetura original, que cumpre um mandato semelhante sob o qual muitas organizações de TI operam. Essa solução alternativa também custa aproximadamente o mesmo que a arquitetura original, mas não fornece os benefícios que a arquitetura replataforma oferece. Por exemplo:
Economia de licenciamento: A solução alternativa retém o WebSphere e adiciona mais nós RHEL.
Eficiência operacional: A solução alternativa mantém o mesmo número de servidores a manter.
Agilidade nos negócios: com a solução alternativa, os relatórios permanecem limitados apenas a noites, sem análise de dia inteiro alimentada por dimensionamento automático.
Detalhes do cenário
Escolha um modelo sem servidor ou sem servidor, dependendo da portabilidade de seus aplicativos existentes e da preferência de fluxo de trabalho e roteiro de tecnologia da sua equipe.
Como a arquitetura original, a arquitetura replataformada tem um banco de dados Oracle, mas é replataformada para um sistema operacional RHEL em Máquinas Virtuais do Azure. Para o Serviço de Aplicativo do Azure totalmente gerenciado na arquitetura replataformada, o Red Hat JBoss EAP substitui o aplicativo WebSphere Java.
Arquitetura (original)
Transfira um ficheiro do Visio desta arquitetura.
Fluxo de Trabalho
Este fluxo de trabalho corresponde à arquitetura anterior.
As solicitações do usuário e as integrações de API de entrada são transferidas para o balanceador de carga F5 local em TCP/443 (HTTPS) e, em seguida, revertem o proxy para vários Java Web Services hospedados pelo IBM WebSphere.
Java Web Services interroga o banco de dados Oracle via TCP/1521. Na maioria dos casos, o tempo de resposta de solicitação da Web síncrona é inferior a 1 segundo (seg), mas superior a 300 ms, de acordo com testes e análise de weblog.
Uma solicitação assíncrona, como o agendamento de uma tarefa em lote, coloca um registro em uma tabela de banco de dados Oracle que atua como uma fila dentro da camada de aplicativo.
Um trabalho cron, escrito em script ksh, consulta a fila no banco de dados Oracle e seleciona trabalhos de análise SAS para serem executados. O cliente deve fazer o processamento em lote à noite para limitar o efeito no desempenho do sistema durante o horário comercial.
Os alertas por e-mail notificam os usuários e administradores via SMTP (TCP/25) sobre os tempos de início e conclusão do trabalho e os resultados de sucesso ou falha.
Os resultados do trabalho de análise vão para uma unidade compartilhada via NFS (TCP+UDP/111,2049) para coleta via SMBv3 (TCP/445).
Detalhes do cenário
Essa arquitetura original avalia um aplicativo Java monólito que é executado no IBM WebSphere e avalia o processamento em lote do SAS que os scripts ksh orquestram. Um banco de dados Oracle executado em um host AIX separado suporta ambas as cargas de trabalho de aplicativos.
Considere sua carga de trabalho original executada no AIX para determinar se uma estratégia de migração de replataforma se adequa ao seu orçamento de migração. Trabalhe para trás a partir dos resultados desejados para determinar um caminho de migração transformador e centrado em aplicativos para a nuvem. Certifique-se de que a maior parte do código do seu aplicativo seja escrita em uma linguagem suportada por serviços nativos da nuvem, como arquiteturas sem servidor e orquestradores de contêineres.
Nesse cenário, o Tidal Accelerator analisou o código da aplicação Java e determinou sua compatibilidade com o JBoss EAP. No início do projeto, o Azure Pipelines ou GitHub Actions é usado para reconstruir o aplicativo como um piloto. O cliente pode então estabelecer agilidade a partir de pipelines de integração contínua e entrega contínua (CI/CD) em um serviço gerenciado, como o Serviço de Aplicativo do Azure. O cliente não pode obter esse recurso em seu ambiente WebSphere local.
Este exemplo retém o banco de dados Oracle nesta fase devido à quantidade de PL/SQL que o Tidal Accelerator descobriu durante a fase de análise. Os esforços futuros do cliente incluem a migração do banco de dados Oracle no RHEL para um banco de dados do Azure para PostgreSQL totalmente gerenciado, a adoção do Armazenamento de Filas do Azure e a execução de trabalhos SAS totalmente sob demanda. Esses esforços estão alinhados com o roteiro de tecnologia do cliente, os ciclos de desenvolvimento e a direção de negócios que foi determinada na entrevista com o proprietário do aplicativo. A captura de tela a seguir mostra uma entrevista no Tidal Accelerator.
Potenciais casos de utilização
Você pode usar essa arquitetura para migrações do AIX para o Azure que abrangem análise de dados, gerenciamento de relacionamento com o cliente (CRM), camadas de integração de mainframe em uma configuração de nuvem híbrida e outras soluções de software personalizadas em cenários de gerenciamento de estoque e depósito.
Você pode usar essa arquitetura para cargas de trabalho de aplicativos tradicionais com tecnologias como:
- Oracle Siebel
- Oracle E-Business Suite
- SAS
- IBM BPM
Considerações
Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que podem ser usados para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.
Fiabilidade
A confiabilidade garante que seu aplicativo possa atender aos compromissos que você assume com seus clientes. Para obter mais informações, consulte Lista de verificação de revisão de design para confiabilidade.
Essa arquitetura usa o Azure Site Recovery para espelhar o banco de dados das VMs do Azure em uma região secundária do Azure para failover rápido e recuperação de desastres se uma região inteira do Azure falhar. Da mesma forma, os Arquivos do Azure usam armazenamento com redundância geográfica.
Os nós de processamento de dados usam discos gerenciados com redundância de zona (RA-ZRS) para fornecer resiliência durante interrupções de zona. Durante uma interrupção de região inteira, você pode reprovisionar nós de processamento de dados em uma região diferente da imagem da VM na Galeria de Computação do Azure redundante.
Segurança
A segurança oferece garantias contra ataques deliberados e o abuso de seus valiosos dados e sistemas. Para obter mais informações, consulte Lista de verificação de revisão de design para segurança.
Essa arquitetura adota uma abordagem de infraestrutura imutável para implantações de aplicativos e verifica proativamente o código nos pipelines do Azure para ajudar a proteger dados confidenciais em produção. Ele incorpora uma abordagem de deslocamento à esquerda para verificação de segurança e frequentemente executa implantações habilitadas para pipeline de CI/CD para melhorar a aderência atual do software e reduzir a dívida técnica.
Otimização de custos
A otimização de custos consiste em procurar formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Lista de verificação de revisão de design para otimização de custos.
Esta solução remove o maior número possível de componentes de servidor, o que reduz os custos operacionais em mais de 70%. Essa arquitetura reduz os custos de computação e licenciamento de software.
Excelência operacional
A excelência operacional abrange os processos operacionais que implantam um aplicativo e o mantêm em execução na produção. Para obter mais informações, consulte Lista de verificação de revisão de design para excelência operacional.
A equipe de produto oferece suporte a si mesma no Azure, o que reduz o tempo de resolução de tíquetes de incidentes relatados. Além disso, a contagem de rejeição de tíquetes, ou o número de tíquetes atribuídos de um grupo para outro, é zero porque uma equipe de produto dá suporte a toda a pilha de aplicativos no Azure.
Eficiência de desempenho
Eficiência de desempenho é a capacidade da sua carga de trabalho para dimensionar para satisfazer as exigências que os utilizadores lhe colocam de forma eficiente. Para obter mais informações, consulte Lista de verificação de revisão de projeto para eficiência de desempenho.
O cliente adota o Serviço de Aplicativo do Azure sempre que possível para que possa aumentar e expandir automaticamente seus requisitos de computação para se alinhar à demanda do aplicativo. Essa elasticidade garante um desempenho consistente do aplicativo durante os horários de pico. Esta abordagem também é eficiente em termos de custos.
Contribuidores
Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.
Autor principal:
Richard Berry| Gerente de Programa Sr.
Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.
Próximos passos
Para obter mais informações sobre como usar uma solução Tidal Accelerator, contate a equipe do Microsoft Tidal Cloud.
Para obter mais informações sobre como migrar para o Azure, entre em contato com a equipe de Engenharia de Migrações Herdadas.