Tipi di distribuzione di applicazioni
È possibile distribuire le applicazioni Java nel cloud in modi diversi. In questa unità verranno esaminate le varie opzioni disponibili per consentire di comprendere meglio i servizi di Azure illustrati nell'unità successiva.
Macchine virtuali, contenitori e piattaforma distribuita come servizio?
La domanda più importante da porsi è se si vuole o si deve distribuire l'applicazione in una macchina virtuale, in un contenitore o in una soluzione PaaS (Platform as a Service, piattaforma distribuita come servizio).
Le macchine virtuali offrono un ambiente simile a un sistema locale o a un data center classico. Azure fornisce un set di macchine virtuali preconfigurate che eseguono i principali sistemi operativi (Windows e Linux), ma che richiedono un impegno in termini di configurazione e gestione.
È preferibile adottare una soluzione di questo tipo all'inizio, perché è la più simile all'ambiente già usato dalle aziende prima del passaggio al cloud. In genere le aziende 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 come facevano in passato.
La soluzione basata su macchine virtuali è efficace se si può contare su un team operativo esperto, che provvederà a configurarle e gestirle, e se si devono gestire casi d'uso specifici. Ad esempio, se si usano alcune librerie native oppure un prodotto software proprietario, come Oracle WebLogic Server o IBM WebSphere Server.
I contenitori consentono di mantenere la maggior parte del controllo di cui si può disporre usando le macchine virtuali, ma con un minore impegno sul piano operativo. È possibile installare la propria istanza di Java Virtual Machine (JVM) o un prodotto software specifico e i contenitori verranno eseguiti in locale o in qualsiasi provider di servizi cloud.
Poiché consentono una notevole libertà, i contenitori presentano alcuni dei problemi tipici delle macchine virtuali. Se si usa un'istanza specifica di JVM, sarà necessario aggiornarla e applicarvi patch, quando necessario. Di conseguenza, le immagini Docker richiedono una valida toolchain CI/CD per una corretta gestione dei contenitori. Poiché le immagini Docker possono essere eseguite in locale e sono più leggere delle macchine virtuali, offrono anche un'esperienza di sviluppo ottimale.
Con una soluzione di piattaforma distribuita come servizio (PaaS), la manutenzione e il funzionamento vengono gestiti prevalentemente dal provider di servizi cloud. Vengono forniti tutti gli aggiornamenti del sistema operativo, le patch Java, le funzionalità di sicurezza e la conformità. Di conseguenza, questa opzione è in genere più sicura e meno costosa, oltre a includere alcune funzionalità di scalabilità, che consentiranno all'applicazione di adattarsi meglio alle esigenze dei clienti. Garantisce inoltre prestazioni migliori in condizioni di carico e prezzi più bassi in caso di traffico ridotto.
Una soluzione PaaS offre anche altri vantaggi. È possibile impostare 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
Che si usino macchine virtuali, contenitori o una soluzione PaaS, in genere è possibile distribuire le applicazioni Java nel cloud in uno di questi due modi:
- 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, crea e inserisce in 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 rappresentano le modalità classiche di esecuzione delle applicazioni Java. Il processo di compilazione è in genere simile per entrambe le opzioni. La differenza principale è data dalla posizione in cui viene eseguito il processo. Consentendo al provider di servizi cloud di eseguire la compilazione, si usufruisce di una soluzione più semplice e, con questo approccio, il provider applica specifici controlli di sicurezza e patch. Compilando l'applicazione in locale (o usando una piattaforma CI/CD come GitHub Actions) si può contare su maggiore flessibilità e controllo.
Funzioni serverless
Le funzioni serverless o, più in particolare, Funzioni di Azure, consistono in una combinazione di varie soluzioni già esaminate e presentano una caratteristica molto specifica: devono essere eseguite per brevi periodi di tempo. Una funzione viene in genere attivata da un evento, ad esempio una richiesta HTTP, e rimane "attiva" per alcuni minuti, finché non torna in sospensione.
Le funzioni condividono alcune 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 parte del codice.
Per le opzioni di distribuzione, le funzioni usano in genere i file JAR. Sono disponibili altre opzioni, ad esempio Docker, ma sono meno diffuse e in genere non offrono lo stesso livello di prestazioni. Ciò è dovuto al fatto che la piattaforma sottostante non riesce a ottimizzarle allo stesso modo dei file JAR.
Per loro natura, le funzioni serverless devono essere codificate in modo specifico. Le caratteristiche di queste funzioni dipendono dal provider di servizi cloud in cui vengono eseguite e la breve durata rende difficoltoso l'uso di soluzioni tradizionali, come la memorizzazione nella cache o la replica delle sessioni HTTP.
Le funzioni serverless sono facilmente scalabili e offrono il prezzo migliore per gli ambienti a basso utilizzo. Allo stesso tempo, riescono a gestire i carichi di traffico più impegnativi.