Editar

Partilhar via


Compare as opções de hospedagem de aplicativos Java no Azure

Azure Spring Apps
Azure App Service
Azure Kubernetes Service (AKS)
Azure Virtual Machines

O Azure oferece muitas opções para as equipes criarem e implantarem aplicativos Java. Este artigo aborda os principais cenários para Java no Azure e fornece sugestões e considerações de planejamento de alto nível.

Apache®, Apache Kafka, Apache Struts, Apache Tomcat e o logotipo flame são marcas registradas ou marcas comerciais da Apache Software Foundation nos Estados Unidos e/ou em outros países. Nenhum endosso da Apache Software Foundation está implícito no uso dessas marcas.

Plataforma

Antes de selecionar um cenário de nuvem para seu aplicativo Java, identifique sua plataforma. A maioria das aplicações Java usa uma das seguintes plataformas:

Aplicações JAR Spring Boot

Os aplicativos JAR do Spring Boot normalmente são invocados diretamente da linha de comando. Eles lidam com solicitações da Web. Em vez de depender de um servidor de aplicativos para lidar com solicitações HTTP, esses aplicativos incorporam comunicação HTTP e outras dependências diretamente no pacote de aplicativos. Tais aplicativos geralmente são construídos com estruturas como Spring Boot, Dropwizard, Micronaut, MicroProfile e Vert.x.

Esses aplicativos são empacotados em arquivos que têm a extensão .jar , conhecidos como arquivos JAR.

Aplicações 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. Esses serviços são criados em torno de recursos de negócios.

O maquinário de implantação automatizada implanta esses microsserviços de forma independente. Há um mínimo de gerenciamento centralizado, que pode ser escrito em diferentes linguagens de programação e usar diferentes tecnologias de armazenamento de dados. Esses serviços geralmente são construídos com estruturas como o Spring Cloud.

Esses serviços são empacotados em vários aplicativos como arquivos JAR.

Aplicações Web

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

Os aplicativos da Web são empacotados em arquivos que têm a extensão .war , conhecida como arquivos WAR.

Aplicações Jacarta EE

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

Os aplicativos de Jacarta EE podem ser empacotados como arquivos WAR ou como arquivos que têm a extensão .ear , conhecida como arquivos EAR.

Os aplicativos Jakarta EE devem ser implantados em servidores de aplicativos que sejam compatíveis com Jakarta EE. Exemplos incluem WebLogic, WebSphere, WildFly, GlassFish e Payara.

Os aplicativos que dependem apenas dos recursos fornecidos pela especificação Jakarta EE podem ser migrados de um servidor de aplicativos compatível para outro. Se seu aplicativo depender de um servidor de aplicativos específico, talvez seja necessário selecionar um destino de serviço do Azure que permita hospedar esse servidor de aplicativos.

Opções da plataforma

Use a tabela a seguir para identificar plataformas potenciais para seu tipo de aplicativo.

Azure Spring Apps Serviço de Aplicativo Java SE Serviço de Aplicativo Tomcat Serviço de Aplicativo JBoss EAP Azure Container Apps AKS Máquinas Virtuais
Aplicações do Spring Boot/JAR
Aplicações Spring Cloud
Aplicações Web
Aplicações Jacarta EE
Disponibilidade da região do Azure Detalhes Detalhes Detalhes Detalhes Detalhes Detalhes Detalhes

O Serviço Kubernetes do Azure (AKS) e as Máquinas Virtuais dão suporte a todos os tipos de aplicativos, mas exigem que sua equipe assuma mais responsabilidades, conforme descrito na próxima seção.

Capacidade de Suporte

Além das escolhas de plataforma, as aplicações Java modernas podem ter outras necessidades de suporte, tais como:

Trabalhos em lote ou agendados

Em vez de aguardar solicitações ou entrada do usuário, alguns aplicativos são executados brevemente, executam uma carga de trabalho específica e, em seguida, saem. Às vezes, esses trabalhos precisam ser executados uma vez ou em intervalos regulares e programados. No local, esses trabalhos são frequentemente invocados a partir da tabela cron de um servidor.

Esses aplicativos são empacotados como arquivos JAR.

Nota

Se seu aplicativo usa um agendador, como Spring Batch ou Quartz, para executar tarefas agendadas, é altamente recomendável que você execute essas tarefas fora do aplicativo. Se seu aplicativo for dimensionado para várias instâncias na nuvem, o mesmo trabalho poderá ser executado mais de uma vez. Se o mecanismo de agendamento usar o fuso horário local do host, pode haver um comportamento indesejado quando você dimensiona um aplicativo entre regiões.

Integração da rede virtual

Quando você implementa um aplicativo Java em sua rede virtual, ele tem dependências de saída em serviços fora da rede virtual. Para gerenciamento e operações, seu projeto deve ter acesso a determinadas portas e nomes de domínio totalmente qualificados. Com as Redes Virtuais do Azure, pode colocar muitos dos seus recursos do Azure numa rede não roteável pela Internet. O recurso de integração de rede virtual permite que seus aplicativos acessem recursos em ou por meio de uma rede virtual. A integração de rede virtual não permite que seus aplicativos sejam acessados de forma privada.

Modelo de desenvolvimento sem servidor

Serverless é um modelo de desenvolvimento nativo da nuvem que permite aos desenvolvedores criar e executar aplicativos sem ter que gerenciar servidores. Com aplicações sem servidor, o fornecedor de serviços cloud aprovisiona, dimensiona e gere automaticamente a infraestrutura subjacente necessária para executar o código. Os servidores ainda existem no modelo sem servidor. Eles são abstraídos do desenvolvimento de aplicativos.

Contentorização

A conteinerização é o empacotamento de código de software com todos os seus componentes necessários, como bibliotecas, estruturas e outras dependências. O aplicativo é isolado em seu próprio contêiner.

CI/CD

A integração contínua e a entrega contínua (CI/CD) são um método para entregar frequentemente aplicativos aos clientes, introduzindo a automação nos estágios de desenvolvimento de aplicativos. Os principais conceitos em CI/CD são integração contínua, entrega contínua e implantação contínua. Todas as opções do Azure suportam a maioria das ferramentas de CI/CD. Por exemplo, você pode usar soluções como Azure Pipelines ou Jenkins.

Motor de pesquisa de código aberto

As pesquisas são parte integrante de qualquer aplicação. Se a velocidade, o desempenho e a alta disponibilidade forem críticos, as pesquisas em terabytes e petabytes de dados podem ser desafiadoras. Ao hospedar aplicativos Java no Azure, planeje hospedar suas instâncias relacionadas do Solr e do Elasticsearch. Como alternativa, considere migrar para a Pesquisa Cognitiva do Azure.

Ferramentas de Big Data

As ferramentas de Big Data permitem a automatização do fluxo de dados entre os sistemas de software. Eles suportam gráficos de roteamento de dados escaláveis, robustos e simplificados, juntamente com a lógica de mediação do sistema. Eles são utilizados para criar pipelines de fluxo de dados ao vivo e aplicativos de streaming. Saiba como o Nifi e o Apache Kafka no Azure podem ser adequados às suas necessidades.

Opções de suporte

Use a tabela a seguir para identificar possíveis opções para seu tipo de aplicativo. O AKS e as Máquinas Virtuais suportam todos os tipos de aplicações, mas exigem que a sua equipa assuma mais responsabilidades.

Azure Spring Apps Serviço de Aplicativo Java SE Serviço de Aplicativo Tomcat Serviço de Aplicativo JBoss EAP Azure Container Apps AKS Máquinas Virtuais
Trabalhos em lote ou agendados
Integração da rede virtual
Sem servidor
Contentorização
Disponibilidade da região do Azure Detalhes Detalhes Detalhes Detalhes Detalhes Detalhes Detalhes

Consulte também esta árvore de decisão.

O diagrama mostra uma árvore de decisão para Java nos serviços do Azure.

Baixe um arquivo do Visio deste diagrama.

Construa ou migre aplicativos Java

Para construir ou migrar as aplicações Java, identifique a plataforma Java das suas aplicações. Algumas plataformas populares são Java SE, Jakarta EE e MicroProfile.

Java SE

Java Platform, Standard Edition (Java SE) é uma plataforma de computação para o desenvolvimento e implementação de código portátil para ambientes desktop e servidor. Projetos populares construídos em Java SE incluem Spring Boot, Spring Cloud, Spring Framework e Apache Tomcat.

Jakarta EE

Jakarta EE é o futuro de código aberto do Java empresarial nativo da nuvem. É um conjunto de especificações que estendem o Java SE com recursos corporativos, como computação distribuída e serviços web. Os aplicativos Jakarta EE executam tempos de execução de referência. Esses tempos de execução podem ser microsserviços ou servidores de aplicativos. Eles lidam com transações, segurança, escalabilidade, simultaneidade e gerenciamento dos componentes que o aplicativo implanta.

MicroProfile

O projeto MicroProfile fornece uma coleção de especificações projetadas para ajudar os desenvolvedores a criar microsserviços nativos da nuvem Enterprise Java. Quarkus e Open Liberty são implementações populares do MicroProfile.

Compilar ou migrar resumo

A tabela a seguir fornece informações de compilação ou migração por tipo de aplicativo e serviço do Azure.

Type Java SE MicroProfile Jarcarta
Máquina Virtual IaaS
VMware Tanzu IaaS
Azure Kubernetes Service Contentor
Red Hat OpenShift Contentor
Aplicativo de Contêiner do Azure PaaS
JBoss EAP Serviço de Aplicativo PaaS
Apache Tomcat Serviço de Aplicativo PaaS
Java SE Serviço de Aplicativo PaaS
Azure Spring Apps PaaS

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Principais autores:

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Próximos passos