Este artigo descreve uma abordagem de migração a fim de redefinir a plataforma das cargas de trabalho AIX para a nuvem. Você pode usar o Azure Functions em uma arquitetura sem servidor ou usar as Máquinas Virtuais do Azure para manter um modelo com servidor.
Leve em consideração uma estratégia de migração de redefinição da plataforma para cargas de trabalho AIX a fim de maximizar o retorno sobre o investimento (ROI) ao migrar aplicativos herdados para o Azure. As migrações de redefinição da plataforma exigem alterações mínimas, mas oferecem benefícios nativos da nuvem semelhantes a uma migração de refatoração.
Entre os benefícios de uma migração de redefinição da plataforma estão:
- Um custo total de propriedade (TCO) reduzido.
- Melhoria na agilidade dos negócios.
- Mais resiliência operacional.
Arquitetura (plataforma redefinida)
Baixe um Arquivo Visio dessa arquitetura.
Workflow
Esse workflow corresponde à arquitetura anterior.
As solicitações de usuário e as integrações da API de entrada são transferidas para o Gateway de Aplicativo do Azure em TCP/443 (HTTPS), que oferece uma funcionalidade de firewall do aplicativo Web (WAF). O Gateway de Aplicativo envia as solicitações, como solicitações de proxy reverso, para serviços variados 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 funciona como uma fila dentro da camada de aplicativo.
Observação
No futuro, o Armazenamento de Filas do Azure vai substituir a tabela do banco de dados, de maneira que você sempre possa ter acesso a trabalhos de análise em execução.
O trabalho cron, escrito em script KornShell (ksh), é portado para o Bash e executado em um servidor Red Hat Enterprise Linux (RHEL) à parte em Conjuntos de Dimensionamento de Máquinas Virtuais 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áquinas Virtuais paralelizam trabalhos de análise de execução prolongada. Essa solução não requer processamento em lote fora do pico para limitar o efeito sobre o desempenho do sistema durante o horário comercial.
Os Serviços de Comunicação do Azure enviam alertas de email por meio da ferramenta CLI do Azure (documentos). As identidades gerenciadas atribuídas pelo 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 pelo sistema.
Componentes
O Microsoft Entra ID elimina a confiança baseada em rede e oferece identidades gerenciadas atribuídas ao sistema, o que aumenta 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 Gateway de Aplicativo é um serviço totalmente gerenciado e escalável que oferece Firewall de Aplicativo Web e funcionalidade de proxy reverso.
Os Arquivos do Azure oferecem relatórios de dados publicados por meio de um serviço gerenciado.
O Azure Functions é uma plataforma de computação sem servidor orientada a eventos usada para desenvolver código com eficiência na linguagem de programação especificada.
Uma VM do Azure é usada pelo banco de dados Oracle e pelos nós de análise SAS.
A Galeria de Computação do Azure compila e armazena imagens do banco de dados Oracle e dos nós de análise SAS. Existem duas galerias: uma na região primária e outra na região da recuperação de desastres.
Os Serviços de Comunicação enviam emails com um utilitário CLI. Esse serviço substitui o
mailxcomando no AIX.
Alternativas
Uma alternativa é uma arquitetura completa com servidor que retenha todos os componentes de middleware como estão.
Essa solução é semelhante à arquitetura original, que cumpre um mandato item por item no qual muitas organizações de TI operam. Essa solução alternativa também custa aproximadamente o mesmo que a arquitetura original, mas não oferece os benefícios que a arquitetura de plataforma redefinida. Por exemplo:
Economia no licenciamento: a solução alternativa retém o WebSphere e adiciona mais nós RHEL.
Eficiência operacional: a solução alternativa retém o mesmo número de servidores a serem mantidos.
Agilidade nos negócios: com a solução alternativa, os relatórios permanecem limitados apenas a noites, sem análise de dimensionamento automático durante todo o dia.
Detalhes do cenário
Escolha um modelo sem ou com servidor, dependendo da portabilidade dos aplicativos existentes e da preferência do workflow e do roteiro de tecnologia da equipe.
Assim como a arquitetura original, a arquitetura de plataforma redefinida tem um banco de dados Oracle, mas com a plataforma redefinida para um sistema operacional RHEL em Máquinas Virtuais do Azure. Para o Serviço de Aplicativo do Azure totalmente gerenciado na arquitetura de plataforma redefinida, o Red Hat JBoss EAP substitui o aplicativo WebSphere Java.
Arquitetura (original)
Baixe um Arquivo Visio dessa arquitetura.
Workflow
Esse workflow corresponde à arquitetura anterior.
As solicitações de usuário e as integrações de API de entrada são transferidas para o load balancer F5 local no TCP/443 (HTTPS) e, em seguida, o proxy reverso para vários Java Web Services hospedados no IBM WebSphere.
Java Web Services interroga o banco de dados Oracle por meio de TCP/1521. Na maioria dos casos, o tempo de resposta da solicitação da Web síncrona é inferior a 1 segundo (s), mas superior a 300 ms de acordo com o teste e a análise do blog.
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 funciona 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 durante a noite para limitar o efeito sobre o desempenho do sistema durante o horário comercial.
Os alertas de email notificam os usuários e os administradores por meio de SMTP (TCP/25) das horas de início e conclusão do trabalho e dos resultados de êxito ou falha.
Os resultados do trabalho de análise vão para uma unidade compartilhada por meio de NFS (TCP+UDP/111,2049) para coleta por meio de SMBv3 (TCP/445).
Detalhes do cenário
Essa arquitetura original avalia um aplicativo Java monolítico executado no IBM WebSphere e avalia o processamento em lote do SAS orquestrado pelos scripts ksh. Um banco de dados Oracle executado em um host AIX à parte dá suporte a ambas as cargas de trabalho do aplicativo.
Leve em consideração a carga de trabalho original executada no AIX para determinar se uma estratégia de migração com redefinição de plataforma é indicada para o orçamento de migração. Trabalhe a partir dos resultados desejados para determinar um caminho de migração transformador e centrado em aplicativos para a nuvem. Verifique se a maior parte do código do aplicativo é escrita em uma linguagem compatível com os serviços nativos da nuvem, como arquiteturas sem servidor e orquestradores de contêiner.
Nesse cenário, o Tidal Accelerator analisou o código do aplicativo Java e determinou a compatibilidade com o JBoss EAP. No início do projeto, o Azure Pipelines ou o GitHub Actions é usado para recompilar o aplicativo como um piloto. O cliente pode acabar estabelecendo a agilidade a partir dos 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 consegue obter esse recurso no ambiente WebSphere local.
Este exemplo mantém o banco de dados Oracle nessa fase por causa do volume de PL/SQL descoberto pelo Tidal Accelerator durante a fase de análise. Entre os esforços futuros do cliente estão a migração do banco de dados Oracle em 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 determinados na entrevista com o proprietário do aplicativo. A captura de tela a seguir mostra uma entrevista no Tidal Accelerator.
Possíveis casos de uso
Você pode usar essa arquitetura para migrações do AIX para o Azure abrangendo análise de dados, gerenciamento de relacionamento com o cliente (CRM), camadas de integração do 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 em cargas de trabalho de aplicativos tradicionais com tecnologias como:
- Oracle Siebel
- Oracle E-Business Suite
- SAS
- IBM BPM
Considerações
Estas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios de orientação que podem ser usados para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, confira Microsoft Azure Well-Architected Framework.
Confiabilidade
A confiabilidade garante que seu aplicativo possa cumprir os 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 as VMs do Azure do banco de dados para uma região do Azure secundária tendo em vista um failover rápido e uma recuperação de desastre em caso de falha na região do Azure inteira. Da mesma maneira, os Arquivos do Azure usam armazenamento com redundância geográfica.
Os nós de processamento dos dados usam discos gerenciados com redundância de zona (RA-ZRS) para oferecer resiliência durante paralisaçõ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 de VM dentro da Galeria de Computação do Azure redundante.
Segurança
A segurança fornece garantias contra ataques deliberados e o abuso de seus dados e sistemas valiosos. 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 em implantações de aplicativo e verifica proativamente o código nos pipelines do Azure para ajudar a proteger dados confidenciais na produção. Ela incorpora uma abordagem de deslocamento para a esquerda na verificação de segurança e executa com frequência implantações habilitadas para pipeline CI/CD para melhorar a aderência atual do software e reduzir a dívida técnica.
Otimização de custo
A otimização de custos é a análise de maneiras de reduzir as 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.
Essa solução remove o maior número possível de componentes com 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 de operações 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 se apoia no Azure, o que reduz o tempo de resolução de tíquetes de incidentes relatados. Além disso, a contagem de devolução dos 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
A eficiência do desempenho é a capacidade de dimensionar a carga de trabalho para atender às demandas exigidas pelos usuários de maneira eficiente. Para obter mais informações, consulte Lista de verificação de revisão de design para eficiência de desempenho.
O cliente adota o Serviço de Aplicativo do Azure sempre que possível, de maneira que possa escalar vertical e horizontalmente de maneira automática os requisitos de computação para se alinhar à demanda do aplicativo. Essa elasticidade garante um desempenho de aplicativo consistente durante os horários de pico. Essa abordagem também é econômica.
Colaboradores
Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.
Autor principal:
Richard Berry| Gerente de programas sênior
Para ver perfis não públicos do LinkedIn, entre no LinkedIn.
Próximas etapas
Para obter mais informações sobre como usar uma solução Tidal Accelerator, entre em contato com 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.