Tipos de implantação de aplicativos
Há várias maneiras de implantar aplicativos Java na nuvem. Esta unidade explora as várias opções, de modo que, na próxima unidade, você possa entender melhor os serviços fornecidos pelo Azure.
Máquinas virtuais, contêineres ou plataforma como serviço?
A principal pergunta é se você deseja ou precisa implantar seu aplicativo em uma VM (máquina virtual), dentro de um contêiner ou em uma solução de PaaS (plataforma como serviço).
Com as máquinas virtuais, você está em um cenário semelhante a um ambiente de datacenter local ou clássico. O Azure fornece um conjunto de VMs pré-configuradas que executam os principais sistemas operacionais (Windows e Linux) e você precisará configurar e manter esses computadores.
Sugerimos que, a princípio, você adote essa solução, porque ela é a mais próxima daquilo que a maioria das empresas já usam antes de migrar para a nuvem. Normalmente, elas instalam um software próprio de gerenciamento de configuração, instalam a versão favorita do Java e podem executar a carga de trabalho Java de modo semelhante a como faziam no passado.
A solução de VM funciona bem se você tem uma equipe de operações experiente que vai configurá-la e mantê-la e se tem casos de uso específicos. Por exemplo, você pode estar usando algumas bibliotecas nativas ou um software proprietário, como o Oracle WebLogic Server ou o IBM WebSphere Application Server.
Com os contêineres, você ainda tem a maior parte do controle que tem com as VMs, mas com menos esforço operacional. Você pode instalar sua JVM (Máquina Virtual Java) ou um software específico, e seus contêineres serão executados no local ou em qualquer provedor de nuvem.
Como os contêineres oferecem muita liberdade, eles apresentam alguns dos mesmos problemas das VMs. Se você fornecer sua JVM, precisará atualizá-la e aplicar patches a ela, conforme necessário. Como resultado, as imagens do Docker exigem uma boa cadeia de ferramentas de CI/CD (integração contínua e entrega contínua) para manter os contêineres adequadamente. Como as imagens do Docker podem ser executadas no local e são mais leves que as VMs, elas também proporcionam uma excelente experiência do desenvolvedor.
Com uma solução de plataforma como serviço, o provedor de nuvem administra a maior parte da carga de manutenção e operação. Atualizações do sistema operacional, patches do Java, segurança e conformidade são todos fornecidos. Como resultado, opção costuma ser mais segura e apresentar um custo menor. Ela também vem com alguns recursos de escalabilidade, o que deve permitir que o seu aplicativo se adapte melhor às necessidades dos clientes. Além disso, ele resulta em melhor desempenho sob carga e em menor custo quando há menos tráfego.
Faça mais usando uma solução de PaaS. Defina uma configuração automática, gerencie e carregue segredos (por exemplo, usando o Azure Key Vault), monitore seu aplicativo, inicie uma sessão de criação de perfil em tempo real e habilite a implantação sem tempo de inatividade.
Opções de implantação
Independentemente de você usar VMs, contêineres ou uma solução de PaaS, normalmente, você pode implantar seus aplicativos Java na nuvem de uma destas duas maneiras:
- Implantação de código-fonte: você faz commit do seu código-fonte em um repositório Git e o provedor de nuvem executa um processo que compila, cria e empacota o aplicativo.
- Implantação de arquivo JAR, WAR ou EAR: você empacota seu aplicativo, normalmente como um arquivo JAR (Java ARchive) executável, mas o formato de arquivo WAR (Web Application ARchive), EAR (Enterprise Application ARchive) e outros também são possíveis. O provedor de nuvem então executa o arquivo executável.
Essas duas opções de implantação são maneiras clássicas de executar aplicativos Java. Em ambas as opções, geralmente, o processo de build é semelhante, e a principal diferença é o local em que esse processo é executado. É mais simples permitir que o provedor de nuvem faça o build. Com essa abordagem, ele aplica verificações de segurança e patches próprios. Ao compilar o aplicativo no local ou usando uma plataforma de CI/CD, como o GitHub Actions, você obtém mais flexibilidade e controle.
Funções sem servidor
As funções sem servidor ou, mais especificamente, o Azure Functions, são uma combinação de várias soluções já vistas e oferecem um recurso muito específico: as funções sem servidor devem ser executadas por períodos curtos. Uma função costuma ser ativada por um evento, como uma solicitação HTTP, e permanece "quente" por alguns minutos, até que volte para a suspensão.
As funções compartilham recursos com a solução de PaaS que descrevemos anteriormente. No Azure, a solução de PaaS (Serviço de Aplicativo do Azure) e a solução sem servidor (Azure Functions) são tecnicamente semelhantes e compartilham alguns códigos e serviços.
Para opções de implantação, as funções geralmente funcionam com arquivos JAR. Outras opções, como o Docker, estão disponíveis, mas elas são menos populares e, no geral, não têm um bom desempenho. Isso ocorre porque a plataforma subjacente não pode otimizá-las da mesma forma que faz para os arquivos JAR.
Por natureza, as funções sem servidor precisam ser especificamente codificadas. Os recursos dessas funções dependem do provedor de nuvem em que são executadas, e a vida curta delas torna complicado o uso de soluções tradicionais, como cache ou replicação de sessão HTTP.
As funções sem servidor podem ser bem escaladas e oferecem o melhor preço para ambientes de baixo uso. Ao mesmo tempo, elas podem responder às cargas de tráfego mais exigentes.