Migrar aplicativos Java para o Azure

Este artigo fornece uma visão geral das estratégias recomendadas para migrar aplicativos Java para o Azure.

Essas diretrizes de migração foram projetadas para abranger cenários predominantes de Java no Azure e fornecer sugestões e considerações de planejamento de alto nível. Se desejar discutir um cenário de migração de aplicativo Java específico com a equipe do Microsoft Java no Azure, preencha o questionário a seguir e um representante entrará em contato com você.

Identificar o tipo do aplicativo

Antes de selecionar um destino de nuvem para seu aplicativo Java, você precisará identificar qual é o tipo do aplicativo. A maioria dos aplicativos Java são de um dos seguintes tipos:

• Aplicativos Spring:
  • Aplicativos Spring Boot/JAR
  • Aplicativos Spring que usam módulos de middleware Spring Cloud
• Aplicativos Java EE
• Aplicativos Web
• Trabalhos agendados/em lotes

Esses tipos são descritos nas seções a seguir.

Aplicativos Spring Boot/JAR

Muitos aplicativos mais recentes são invocados diretamente da linha de comando. Esses aplicativos ainda manipulam solicitações da Web, mas em vez de depender de um servidor de aplicativos para fornecer manipulação de solicitações HTTP, eles incorporam a comunicação HTTP e todas as outras dependências diretamente no pacote de aplicativos. Esses aplicativos são frequentemente criados com estruturas como Spring Boot, Dropwizard, Micronaut, MicroProfile, Vert.x e outros.

Esses aplicativos são empacotados em arquivos com a extensão .jar (arquivos JAR).

Aplicativos Spring que usam módulos de middleware Spring Cloud

O estilo de arquitetura de microsserviços é uma abordagem para desenvolvimento de um único aplicativo como um conjunto de pequenos serviços. Cada serviço é executado em seu próprio processo e se comunica usando mecanismos leves, geralmente uma API de recurso HTTP. Esses serviços são criados com base em recursos de negócios e são implantáveis independentemente por um maquinário de implantação totalmente automatizado. Há um mínimo de gerenciamento centralizado desses serviços, que pode ser escrito em linguagens de programação diferentes e usar tecnologias de armazenamento de dados diferentes. Esses serviços são frequentemente criados com estruturas como o Spring Cloud.

Esses serviços são empacotados em vários aplicativos com a extensão .jar (arquivos JAR).

Aplicativos Java EE

Aplicativos Java EE (também conhecidos como aplicativos J2EE ou, mais recentemente, aplicativos Jakarta EE) podem conter alguns, todos ou nenhum dos elementos de aplicativos Web. Esses aplicativos também podem conter e consumir muito mais componentes, conforme definido pela especificação Jakarta EE.

Os aplicativos Java EE podem ser empacotados como arquivos com a extensão .ear (arquivos EAR) ou como arquivos com a extensão .war (arquivos WAR).

Os aplicativos Java EE devem ser implantados em servidores de aplicativos compatíveis com Java EE (como Oracle WebLogic Server, IBM WebSphere, JBoss EAP, GlassFish, Payara e outros).

Os aplicativos que dependem apenas dos recursos fornecidos pela especificação Java EE (ou seja, aplicativos independentes de servidor de aplicativo) podem ser migrados de um servidor de aplicativos que esteja em conformidade para outro. Se o aplicativo for dependente de um servidor de aplicativos específico (dependente de servidor de aplicativos), talvez seja necessário selecionar um destino do serviço do Azure que permita hospedar o servidor de aplicativos.

Aplicativos Web

Os aplicativos Web são executados dentro de um contêiner Servlet. Alguns desses aplicativos usam APIs de servlet diretamente, enquanto muitos usam outras estruturas que encapsulam APIs de servlet, como Apache Struts, Spring MVC, JSF (JavaServer Faces) e outros.

Aplicativos Web são empacotados em arquivos com a extensão .war (arquivos WAR).

Trabalhos agendados/em lotes

Alguns aplicativos devem ser executados brevemente, executar uma carga de trabalho específica e, em seguida, sair em vez de esperar por solicitações ou entrada do usuário. Às vezes, esses trabalhos precisam ser executados uma vez ou em intervalos regulares agendados. No local, esses trabalhos são geralmente invocados do crontab de um servidor.

Esses aplicativos são empacotados em arquivos com a extensão .jar (arquivos JAR).

Selecionar o destino do serviço do Azure de destino

As seções a seguir mostram quais destinos de serviço atendem aos requisitos do aplicativo e quais responsabilidades eles envolvem.

Grade de opções de hospedagem

Use a grade a seguir para identificar possíveis destinos para seu tipo de aplicativo. Como você pode ver, o Serviços de Kubernetes do Azure (AKS) e as Máquinas Virtuais do Azure dão suporte a todos os tipos de aplicativo, mas exigem que sua equipe assuma mais responsabilidades, conforme mostrado na próxima seção.

Grade de responsabilidade em andamento

Use a grade a seguir para entender a responsabilidade que cada destino coloca sobre a sua equipe após a migração.

As tarefas indicadas com são gerenciadas total ou principalmente pelo Azure. Sua equipe é responsável continuamente pelas tarefas indicadas com . É recomendável implementar um processo robusto e altamente automatizado para atender a todas essas responsabilidades.

Destino → Tarefa ↓	Aplicativo Serviço	Azure Contêiner Aplicativos	AKS	Máquinas Virtuais
Atualizando bibliotecas (incluindo a correção de vulnerabilidades)	👉	👉	👉	👉
Atualizando o servidor de aplicativos (incluindo a correção de vulnerabilidades)		👉	👉	👉
Atualizando o Java Runtime (incluindo a correção de vulnerabilidades)		👉	👉	👉
Disparando atualizações do Kubernetes (executado pelo Azure com um gatilho manual)	N/D		👉	N/D
Recuperação de Desastre		👉	👉
Reconciliar alterações de API de Kubernetes não compatíveis com versões anteriores	N/D	👉	👉	N/D
Atualizar imagem base do contêiner (incluindo a correção de vulnerabilidades)	N/D	👉	👉	N/D
Atualizar o sistema operacional (incluindo a correção de vulnerabilidades)			1	👉
Detectar e reiniciar instâncias com falha				👉
Implementar a reinicialização sem interrupção e com descarga para atualizações				👉
Gerenciamento de infraestrutura		👉	👉	👉
Monitoramento e gerenciamento de alertas	👉	👉	👉	👉

¹ Algumas atualizações de segurança podem exigir reinicializações de nó, que não são feitas automaticamente. Para mais informações, consulte Aplicar atualizações de kernel e segurança aos nós do Linux no Serviço de Kubernetes do Azure (AKS).

Se você implantar o contêiner do servlet (como o Spring Boot) como parte de seu aplicativo, deverá considerá-lo uma biblioteca e, como tal, sendo sempre sua responsabilidade.

Garantir a conectividade local

Se seu aplicativo precisar acessar qualquer um dos seus serviços locais, você precisará provisionar um dos serviços de conectividade do Azure. Para obter mais informações, consulte Conectar uma rede local ao Azure. Como alternativa, você precisará refatorar seu aplicativo para usar APIs disponíveis publicamente que seus recursos locais expõem.

Você precisa concluir esse esforço antes de iniciar qualquer migração.

Capacidade atual de inventário e uso de recursos

Documente o hardware dos servidores de produção atuais mais as contagens de solicitação média e de pico e o uso de recursos. Você precisará dessas informações para provisionar recursos no destino do serviço.

Guia de migração

Use as grades a seguir para encontrar diretrizes de migração por tipo de aplicativo e por destino de serviço do Azure direcionado.

Aplicativos Java

Use as linhas abaixo para encontrar o tipo do seu aplicativo Java e as colunas para localizar o destino do serviço do Azure que hospedará seu aplicativo.

Se você desejar migrar um aplicativo JBoss EAP para o Tomcat no Serviço de Aplicativo, primeiro converta o aplicativo Java EE em aplicativos Web Java (servlets) em execução no Tomcat e depois siga as diretrizes indicadas abaixo.

Aplicativos Java EE

Use as linhas abaixo para localizar o tipo de aplicativo Java EE em execução em um servidor de aplicativo específico. Use as colunas para localizar o destino do serviço do Azure que hospedará seu aplicativo.

Confira também

• Motivos para migrar para o Java 11 e posterior
• Transição do Java 8 para o Java 11
• Transição do Java 7 para o Java 8