Tipi di distribuzione di applicazioni
Esistono diversi modi per distribuire applicazioni Java nel cloud. Questa unità illustra le varie opzioni in modo che, nell'unità successiva, sia possibile comprendere meglio i servizi offerti da Azure.
Macchine virtuali, contenitori o piattaforma distribuita come servizio?
La domanda principale è se si vuole o è necessario distribuire l'applicazione in una macchina virtuale (VM), all'interno di un contenitore o come soluzione PaaS (Platform as a Service).
Con le macchine virtuali, ci si trova in un mondo simile a un ambiente locale o a un data center classico. Azure offre un set di macchine virtuali preconfigurate che eseguono i sistemi operativi principali (Windows e Linux) e sarà necessario configurare e gestire tali computer.
È consigliabile adottare inizialmente questa soluzione, perché è il più vicino a quello che la maggior parte delle aziende sta già usando prima di passare al cloud. In genere installano il proprio software di gestione della configurazione, installano la versione preferita di Java e possono quindi eseguire il carico di lavoro Java in modo simile a quello in passato.
La soluzione vm funziona bene se si dispone di un team operativo esperto che le configurerà e gestirà e se si dispone di casi d'uso specifici. Ad esempio, è possibile usare alcune librerie native o alcuni software proprietari, ad esempio Oracle WebLogic Server o IBM WebSphere Application Server.
Con i contenitori, si conserva la maggior parte del controllo che si ha con le macchine virtuali, ma con minore sforzo operativo. È possibile installare una macchina virtuale Java (JVM) o un software specifico e i contenitori verranno eseguiti in locale o in qualsiasi provider di servizi cloud.
Poiché i contenitori offrono molta libertà, soffrono di alcuni degli stessi problemi delle macchine virtuali. Se si specifica una JVM personalizzata, è necessario aggiornarla e applicare patch in base alle esigenze. Di conseguenza, le immagini Docker richiedono una buona toolchain di integrazione continua e recapito continuo (CI/CD) per gestire correttamente i contenitori. Poiché le immagini Docker possono essere eseguite in locale e sono più leggere rispetto alle macchine virtuali, offrono anche un'esperienza di sviluppo ottimale.
Con una soluzione di piattaforma distribuita come servizio , il provider di servizi cloud gestisce la maggior parte del carico di manutenzione e funzionamento. Vengono forniti tutti gli aggiornamenti del sistema operativo, le patch Java, la sicurezza e la conformità. Di conseguenza, questa opzione è in genere più sicura e meno costosa. Include anche alcune funzionalità di scalabilità, che dovrebbero consentire all'applicazione di adattarsi meglio alle esigenze dei clienti. Si ottengono anche prestazioni migliori sotto il carico e costi inferiori quando il traffico è minore.
È possibile ottenere di più usando una soluzione PaaS. È possibile configurare la configurazione automatica, gestire e caricare segreti (ad esempio usando Azure Key Vault), monitorare l'applicazione, avviare una sessione di profilatura in tempo reale e abilitare la distribuzione senza tempi di inattività.
Opzioni di distribuzione
Sia che si usino macchine virtuali, contenitori o una soluzione PaaS, in genere è possibile distribuire le applicazioni Java nel cloud in uno dei due modi seguenti:
- Distribuzione del codice sorgente: si esegue il commit del codice sorgente in un repository Git e il provider di servizi cloud esegue un processo che compila, compila e crea pacchetti l'applicazione.
- Distribuzione di file JAR, WAR o EAR: si crea il pacchetto dell'applicazione, in genere come file JAR eseguibile (Java ARchive), ma è possibile usare WAR (Web Application ARchive), EAR (Enterprise Application ARchive) e altri formati di file. Il provider di servizi cloud esegue quindi il file eseguibile.
Queste due opzioni di distribuzione sono modi classici per eseguire applicazioni Java. Per entrambe le opzioni, il processo di compilazione è in genere simile e la differenza principale è la posizione in cui viene eseguito il processo. Consentire al provider di servizi cloud di eseguire la compilazione è più semplice e con questo approccio il provider di servizi cloud applica i propri controlli di sicurezza e patch. Creando l'applicazione in locale o usando una piattaforma CI/CD, ad esempio GitHub Actions, si ottiene maggiore flessibilità e controllo.
Funzioni senza server
Le funzioni serverless, o più in particolare Funzioni di Azure, sono una combinazione di diverse soluzioni che abbiamo visto e offrono una funzionalità molto specifica: le funzioni serverless sono progettate per essere eseguite per brevi periodi di tempo. In genere, una funzione viene riattivata da un evento, ad esempio una richiesta HTTP, e rimane "caldo" per alcuni minuti fino a quando non torna a dormire.
Le funzioni condividono le funzionalità con la soluzione PaaS descritta in precedenza. In Azure, la soluzione PaaS (Servizio app di Azure) e la soluzione serverless (Funzioni di Azure) sono tecnicamente simili e condividono alcuni servizi e codice comuni.
Per le opzioni di distribuzione, le funzioni in genere funzionano con i file JAR. Altre opzioni, ad esempio Docker, sono disponibili, ma sono meno popolari e in genere non funzionano bene. Ciò è dovuto al fatto che la piattaforma sottostante non può ottimizzarle nello stesso modo in cui può essere usato per i file JAR.
Per loro natura, le funzioni serverless devono essere codificate in modo specifico. Le funzionalità dipendono dal provider di servizi cloud da cui vengono eseguite e la loro breve durata rende complicato l'uso di soluzioni tradizionali, ad esempio la memorizzazione nella cache o la replica di sessioni HTTP.
Le funzioni serverless possono essere ridimensionate correttamente e offrono il miglior prezzo per gli ambienti a basso utilizzo. Allo stesso tempo, possono rispondere ai carichi di traffico più impegnativi.