Tipos de implementação de aplicações
Existem várias formas de implementar aplicações Java na cloud. Esta unidade explora as várias opções, para que, na próxima unidade, possa compreender melhor os serviços fornecidos pelo Azure.
Máquinas virtuais, contentores ou plataforma como serviço?
A principal questão é se quer ou precisa de implementar a sua aplicação numa máquina virtual (VM) dentro de um contentor ou como uma solução de plataforma como serviço (PaaS).
Com máquinas virtuais, você está em um mundo 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 essas máquinas.
Sugerimos que adote esta solução inicialmente, uma vez que é a mais parecida com a que a maioria das grandes empresas já está a utilizar antes de mudarem para a cloud. Eles geralmente instalam seu próprio software de gerenciamento de configuração, instalam sua versão favorita do Java e, em seguida, podem executar sua carga de trabalho Java de uma maneira semelhante à que fizeram no passado.
A solução de VM funciona bem, se tiver uma equipa de operações experiente que configure e efetue a manutenção da mesma e se tiver casos de utilização específicos. Por exemplo, poderá estar a utilizar bibliotecas nativas ou software proprietário, como o Oracle WebLogic Server ou o IBM WebSphere Application Server.
Com os contentores, ainda tem a maioria do controlo que tem com as VMs, mas com menos esforço operacional. Você pode instalar sua própria Java Virtual Machine (JVM) ou algum software específico, e seus contêineres serão executados localmente ou em qualquer provedor de nuvem.
Uma vez que os contentores oferecem muita liberdade, têm alguns dos mesmos problemas que as VMs. Se você fornecer sua própria JVM, precisará atualizá-la e corrigi-la conforme necessário. Como resultado, as imagens do Docker exigem uma boa cadeia de ferramentas de integração contínua e entrega contínua (CI/CD) para manter os contêineres corretamente. Uma vez que podem ser executadas localmente e são mais leves do que as VMs, as imagens do Docker proporcionam uma ótima experiência de programação.
Com uma solução de plataforma como serviço, o provedor de nuvem lida com a maior parte da carga de manutenção e operação. São fornecidas atualizações de sistema operativo (SO), patches de Java, segurança e conformidade. Como resultado, esta opção é geralmente mais segura e menos dispendiosa. Também vem com algumas funcionalidades de escalabilidade, o que pode permitir que a sua aplicação se adapte melhor às necessidades dos clientes. Também resulta num melhor desempenho sob carga e em custos mais baixos quando há menos tráfego.
Pode alcançar mais ao utilizar uma solução PaaS. Pode definir uma configuração automática, gerir segredos da carga (por exemplo, ao utilizar o Azure Key Vault), monitorizar a sua aplicação, iniciar uma sessão de análise para otimização em tempo real e ativar a implementação sem tempo de inatividade.
Opções de implementação
Quer você use VMs, contêineres ou uma solução PaaS, geralmente pode implantar seus aplicativos Java na nuvem de duas maneiras:
- Implantação de código-fonte: você confirma seu código-fonte em um repositório Git e o provedor de nuvem executa um processo que compila, compila e empacota o aplicativo.
- Implantação de arquivos JAR, WAR ou EAR: Você empacota seu aplicativo, geralmente como um arquivo JAR executável (Java ARchive), mas WAR (Web Application ARchive), EAR (Enterprise Application ARchive) e outros formatos de arquivo também são possíveis. Em seguida, o provedor de nuvem executa o arquivo executável.
Estas duas opções de implementação são formas clássicas de executar aplicações Java. O processo de compilação é normalmente semelhante para ambas as opções. A principal diferença é o local onde o processo é executado. Permitir que o provedor de nuvem faça a compilação é mais simples e, com essa abordagem, o provedor de nuvem aplica suas próprias verificações e patches de segurança. Ao criar o aplicativo localmente 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 as Funções do Azure, são uma combinação de várias soluções que vimos e oferecem um recurso muito específico: as funções sem servidor devem ser executadas por curtos períodos de tempo. Normalmente, uma função é acionada por um evento (por exemplo, um pedido HTTP) e fica ativa durante alguns minutos antes de voltar a ficar inativa.
As funções compartilham recursos com a solução PaaS que descrevemos anteriormente. No Azure, a nossa solução PaaS (Serviço de Aplicações do Azure) e a nossa solução sem servidor (Funções do Azure) são tecnicamente semelhantes e têm alguns serviços e código em comum.
Para as opções de implementação, as funções geralmente funcionam com ficheiros JAR. Estão disponíveis outras opções, como o Docker, mas são menos populares e, normalmente, não têm um desempenho tão bom. Isto deve-se ao facto de a plataforma subjacente não conseguir otimizá-las da mesma forma que os ficheiros JAR.
Devido à sua natureza, as funções sem servidor precisam de ser codificadas especificamente. Seus recursos dependem do provedor de nuvem no qual são executados, e sua curta vida útil torna complicado o uso de soluções tradicionais, como cache ou replicação de sessão HTTP.
As funções sem servidor podem dimensionar bem e oferecem o melhor preço para ambientes de baixa utilização. Ao mesmo tempo, podem responder às cargas de tráfego mais exigentes.