Migrar aplicações Java para o Azure

Artigo
05/01/2024

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

Esta orientação da migração foi concebida para cobrir os cenários mais comuns do Java no Azure e para fornecer sugestões e considerações de planeamento de alto nível. Se você quiser discutir um cenário específico de migração de aplicativos Java com a equipe do Microsoft Java no Azure, preencha o questionário a seguir e um representante entrará em contato com você.

Questionário sobre migração de Java

Identificar o tipo de aplicação

Antes de selecionar um destino na cloud para a aplicação Java, terá de identificar o tipo de aplicação. A maioria das aplicações Java possui um dos seguintes tipos:

Aplicações de mola:
- Aplicações do Spring Boot/JAR
- Aplicativos Spring que usam módulos de middleware do Spring Cloud
Aplicações Java EE
Aplicações Web
Batch/trabalhos agendados

Estes tipos são descritos nas secções seguintes.

Aplicações do Spring Boot/JAR

Muitas aplicações mais recentes são invocadas diretamente a partir da linha de comandos. Estas aplicações ainda lidam com pedidos Web, mas em vez de dependerem de um servidor de aplicações para fornecer o processamento de pedidos HTTP, incorporam a comunicação HTTP e todas as outras dependências diretamente no pacote de aplicação. Tais aplicações são frequentemente construídas com estruturas como o Spring Boot, Dropwizard, Micronaut, MicroProfile, Vert.x, entre outras.

Estas aplicações são agrupadas em arquivos com a extensão .jar (ficheiros JAR).

Aplicativos Spring que usam módulos de middleware do Spring Cloud

O estilo de arquitetura de microsserviço é uma abordagem para desenvolver 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. Estes serviços são desenvolvidos em torno das capacidades empresariais e são implementáveis de forma independente por máquinas de implementação totalmente automatizadas. Há um mínimo de gerenciamento centralizado desses serviços, que podem ser escritos em diferentes linguagens de programação e usar diferentes tecnologias de armazenamento de dados. Tais serviços são frequentemente desenvolvidos com estruturas como o Spring Cloud.

Estes serviços são agrupados em múltiplas aplicações com a extensão .jar (ficheiros JAR).

Aplicações Java EE

As aplicações Java EE (também referidas como aplicações J2EE ou, mais recentemente, aplicações Jakarta EE) podem conter alguns, todos ou nenhum dos elementos das aplicações Web. Essas aplicações também podem conter e consumir muito mais componentes, conforme definido pela especificação Jakarta EE.

As aplicações Java EE podem ser agrupadas como arquivos com a extensão .ear (ficheiros EAR) ou como arquivos com a extensão .war (ficheiros WAR).

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

As aplicações que dependem apenas de funcionalidades fornecidas pela especificação Java EE (isto é, aplicações independentes de servidores de aplicações) podem ser migradas de um servidor de aplicações compatível para outro. Se a sua aplicação estiver dependente de um servidor de aplicações específico (dependente de servidores de aplicações), poderá ter de selecionar um destino de serviço do Azure que lhe permita alojar esse servidor de aplicações.

Aplicações Web

As aplicações Web são executadas dentro de um contentor Servlet. Alguns desses aplicativos usam APIs de servlet diretamente, enquanto muitos usam outras estruturas que encapsulam APIs de servlet, como Apache Struts, Spring MVC, JavaServer Faces (JSF) e outros.

As aplicações Web são agrupadas em arquivos com a extensão .war (ficheiros WAR).

Batch/trabalhos agendados

Algumas aplicações destinam-se a ser executadas brevemente, a executar uma determinada carga de trabalho e, em seguida, sair em vez de esperar por pedidos ou informação do utilizador. Por vezes, esses trabalhos têm de ser executados uma vez ou em intervalos regulares e agendados. No local, esses trabalhos são frequentemente invocadas a partir do crontab de um servidor.

Estas aplicações são agrupadas em arquivos com a extensão .jar (ficheiros JAR).

Nota

Se a sua aplicação utilizar um agendador (como o Spring Batch ou o Quartz) para executar as tarefas agendadas, recomendamos vivamente que considere que tais tarefas sejam executadas fora da aplicação. Se a sua aplicação dimensionar para várias instâncias na cloud, o mesmo trabalho será executado mais do que uma vez. Além disso, se o seu mecanismo de agendamento utilizar o fuso horário local do anfitrião, poderão ocorrer comportamentos indesejáveis ao dimensionar a sua aplicação entre regiões.

Selecionar o destino de serviço do Azure

As seguintes secções mostram quais os destinos de serviço que cumprem os requisitos da sua aplicação e que responsabilidades envolvem.

Grelha de opções de alojamento

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

Destino → Tipo de aplicação ↓	Aplicação Serviço Java SE	Aplicação Serviço Tomcat	Aplicação Serviço JBoss EAP	Azure Spring Aplicações	Azure Container Apps	AKS	Virtual Computadores
Aplicações do Spring Boot/JAR				✔
Aplicações Spring Cloud				✔	✔	✔	✔
Aplicações Web		✔	✔	✔	✔	✔	✔
Aplicações Java EE			✔			✔	✔
Servidores de aplicações comerciais (como Oracle WebLogic Server ou IBM WebSphere)					✔	✔	✔
Persistência a longo prazo no sistema de ficheiros local	✔	✔	✔			✔	✔
Clustering de aplicações a nível de servidor			✔			✔	✔
Batch/trabalhos agendados				✔	✔	✔	✔
Integração VNet/Conectividade híbrida	✔	✔	✔	✔	✔	✔	✔
Disponibilidade regional do Azure	Detalhes	Detalhes	Detalhes	Detalhes	Detalhes	Detalhes	Detalhes

Grelha de responsabilidade contínua

Utilize a grelha seguinte para entender a responsabilidade que cada destino coloca sobre a sua equipa após a migração.

As tarefas indicadas com Azure são gerenciadas totalmente ou principalmente pelo Azure. Sua equipe é responsável continuamente pelas tarefas indicadas com 👉. Recomendamos a implementação de um processo robusto e altamente automatizado para o cumprimento de todas essas responsabilidades.

Nota

Esta não é uma lista exaustiva de responsabilidades.

Destino → Tarefa ↓	Aplicação Serviço	Azure Spring Aplicações	Azure Contentor Aplicações	AKS	Virtual Computadores
Atualizar bibliotecas (incluindo a remediação de vulnerabilidade)	👉	👉	👉	👉	👉
Atualizar o servidor de aplicações (incluindo a remediação de vulnerabilidade)			👉	👉	👉
Atualizar o Java Runtime (incluindo a remediação de vulnerabilidade)			👉	👉	👉
Acionar atualizações do Kubernetes (realizado pelo Azure com um acionador manual)	N/A			👉	N/A
Recuperação após Desastre			👉	👉
Reconciliar alterações da API Kubernetes não retrocompatíveis	N/A		👉	👉	N/A
Atualizar imagem base do contentor (incluindo a remediação de vulnerabilidade)	N/A		👉	👉	N/A
Atualizar o sistema operativo (incluindo a remediação de vulnerabilidade)				¹	👉
Detetar e reiniciar instâncias falhadas					👉
Implementar drenagem e reinício sem interrupções para atualizações					👉
Gestão de infraestrutura			👉	👉	👉
Monitorização e gestão de alertas	👉	👉	👉	👉

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

Se implementar o contentor servlet (como Spring Boot) como parte da sua aplicação, deve considerá-lo uma biblioteca e, como tal, é sempre da sua responsabilidade.

Garantir a conectividade no local

Se a sua aplicação precisar de aceder a um dos seus serviços no local, tem de aprovisionar um dos serviços de conectividade do Azure. Para obter mais informações, veja como Escolher uma solução para ligar uma rede no local ao Azure. Em alternativa, tem de refatorizar a aplicação para utilizar as APIs publicamente disponíveis que os seus recursos no local expõem.

Deve concluir este procedimento antes de iniciar qualquer migração.

Capacidade atual do inventário e utilização de recursos

Documente o hardware dos servidores de produção atuais mais as contagens médias e máximas de pedidos e utilização de recursos. Vai precisar destas informações para fornecer recursos no destino de serviço.

Documentação de orientação de migração

Utilize as seguintes grelhas para encontrar orientação da migração por tipo de aplicação e destino de serviço do Azure direcionado.

Aplicações Java

Utilize as linhas abaixo para encontrar o tipo de aplicação Java e as colunas para encontrar o destino de serviço do Azure que irá alojar a aplicação.

Se você quiser migrar um aplicativo JBoss EAP para o Tomcat no Serviço de Aplicativo, primeiro converta o aplicativo Java EE em Java Web Apps (servlets) em execução no Tomcat e, em seguida, siga as orientações indicadas abaixo.

Se você quiser migrar um aplicativo Web no Tomcat para o Azure Spring Apps, primeiro converta o aplicativo em aplicativos do Spring Cloud e siga as orientações indicadas abaixo.

Destino → Tipo de aplicação ↓	Aplicação Serviço Java SE	Aplicação Serviço Tomcat	Aplicação Serviço JBoss EAP	Azure Contentor Aplicações	Azure Spring Aplicações	AKS	Virtual Computadores
Aplicações Spring Boot/ JAR	N/A	N/D	N/D	N/A	orientação	N/A	N/A
Spring Cloud/ aplicações	N/A	N/D	N/D	N/A	orientação	orientação planeado	orientação planeado
Aplicações Web no Tomcat	N/A	orientação	N/A	orientação	N/A	orientação	orientação planeado

Aplicações Java EE

Utilize as linhas abaixo para encontrar o tipo de aplicação Java EE a executar num servidor de aplicações específico. Utilize as colunas para encontrar o destino de serviço do Azure que irá alojar a aplicação.

Destino → Servidor de aplicativos ↓	Aplicação Serviço Java SE	Aplicação Serviço Tomcat	Aplicação Serviço JBoss EAP	Azure Contentor Aplicações	Azure Spring Aplicações	AKS	Virtual Computadores
WildFly/ JBoss AS	N/A	N/A	orientação	N/A	N/A	orientação	orientação planeado
Oracle WebLogic Server	N/A	N/A	orientação	N/A	N/A	orientação	orientação
IBM WebSphere	N/A	N/A	orientação	N/A	N/A	orientação	orientação planeado
Red Hat JBoss EAP	N/A	N/A	orientação	N/A	N/A	orientação	orientação