Container, VM e Serverless sono tre dei termini che molti, nel settore Cloud Computing, esaminano da tempo. Il loro costante interesse ha un filo comune che si può riassumere in una domanda: qual è il miglior modo per distribuire e gestire applicazioni in un ambiente cloud?
Se anche tu, sei alla ricerca della risposta a questa domanda, questo articolo ti darà un’idea di quali sono gli approcci attualmente usati dalla maggior parte delle aziende.
Se tradizionalmente ogni applicazione era strettamente collegata al server e al sistema operativo in cui questa veniva eseguita, nel corso degli ultimi anni, e grazie all’avvento dei grandi cloud provider, questa dipendenza è stata ridotta semplificandone l'implementazione: VM, Container e Serverless rappresentano i diversi approcci che permettono di allentare gli stretti legami utilizzati negli ambienti IT tradizionali.
Possiamo considerare il passaggio tra questi approcci come una vera e propria evoluzione degli ambienti cloud computing. Per merito delle loro implementazioni, inoltre, sono sorte molte altre metodologie per eseguire il rilascio di applicazioni, come ad esempio la metodologia DevOps.
Il primo passo: Virtual Machine
Il primo passo in questa evoluzione vede come protagoniste le VM (Virtual Machine), ovvero sistemi operativi installati su hardware “virtuale” completamente isolate le une dalle altre, che hanno il compito di astrarre un ambiente hardware completo, con lo scopo di rendere trasportabile e riproducibile l’intero stack, partendo dal sistema operativo fino all’ applicativo.
Come funziona una VM? Si parte sempre dall’hardware (il server) sul quale viene installato un tipo particolare di programma, chiamato Hypervisor (ad esempio Openstack, VMware, Xen, ecc..) al quale è demandato il compito di fornire e gestire uno stack hardware “virtuale” completo (CPU, Storage, Network, ecc..), su cui l’utente potrà installare il sistema operativo che più si adatta all’esecuzione della propria applicazione.
Attraverso l’utilizzo di VM è possibile eseguire, sullo stesso server fisico, più sistemi operativi contemporaneamente (Windows, Linux, ecc..) in modo del tutto indipendente, aumentando di fatto l’efficienza dell’intero sistema.
Le VM offrono quindi il vantaggio significativo di poter consolidare le applicazioni su un singolo server o sulla medesima infrastruttura fisica, ciò si traduce sicuramente in un incremento notevole di efficienza e flessibilità rispetto ad un approccio tradizionale e non virtualizzato.
Di contro, tuttavia, siccome ogni VM dispone di un proprio sistema operativo, è necessario creare ed utilizzare un’immagine strettamente legata ad esso. In termini di efficienza questa scelta si rivela valida rispetto al tradizionale approccio in cui un server può ospitare un solo Sistema Operativo, pur rimanendo una soluzione non ottimale proprio a causa della quantità di risorse utilizzate, in modo esclusivo, da ciascuna VM per la sola esecuzione del proprio SO. La scelta delle VM come approccio, tuttavia, rimane utile per applicazioni legacy che richiedono un controllo completo sull’ambiente.
Ma per le nuove applicazioni, quale è la soluzione?
Ovviamente, i Container
Mentre le macchine virtuali hanno il compito di virtualizzare l’intero Sistema Operativo, i Container forniscono una virtualizzazione che utilizza parte di questo come substrato in comune tra gli stessi. Ciò comporta che più Container condividano il kernel del SO, fornendo la possibilità all’utente di generare immagini di dimensione ridotte e che siano in grado di utilizzare le librerie del Sistema Operativo in cui vengono eseguite, senza quindi la necessità di incorporarle, riducendo i costi generali e aumentando la velocità di distribuzione e portabilità.
I container, infatti, essendo unità più leggere di isolamento delle applicazioni, includono solamente le librerie e i file necessari per eseguire la singola applicazione che li compone, rendendoli così più veloci ed efficienti rispetto alle VM. Scegliere di utilizzare i Container per distribuire la nostra applicazione fornisce garanzie di portabilità e ripetibilità che non sarebbero possibili con le sole VM.
Anche l’update, e il relativo rollback in caso di problemi, risultano essere notevolmente semplificati. Una volta eseguito un container con la versione dell’immagine modificata, per effettuarne l’update, basterà distruggere lo stesso e in un secondo momento eseguirne un nuovo con la versione precedente dell’immagine, effettuando così un rollback immediato.
Il concetto che sta alla base di questa tecnologia è quello dell’ immutabilità dell’immagine inteso come: ogni immagine contiene solo ed esclusivamente i file, pacchetti e librerie che servono ad eseguire l’applicazione e non può essere modificata. Le modifiche, come detto, dovranno essere effettuate su una nuova immagine che sostituirà la prima. In quest’ottica, i Containers si prestano perfettamente al paradigma CI/CD, permettendo di accedere a una logica di modifica minima e continua, accelerando lo sviluppo di nuove features e la risoluzione di bug.
I container (ahimè) non sono perfetti. Infatti, poiché per natura sono dinamici e flessibili, risulta anche difficile isolarli gli uni dagli altri sullo stesso kernel, proprio in virtù della loro principale caratteristica: condividere “parti” del Sistema Operativo su cui girano.
Next Step: Serverless
Con il Serveless viene eliminata la necessità di gestire l’infrastruttura sottostante all’applicazione.
Concretamente, in questo modello è possibile scrivere il codice, impostare alcuni parametri di configurazione e dare in pasto l’intera applicazione ad un servizio di automation, con l’obiettivo ultimo di avere un ambiente operativo e funzionante senza conoscere l’effettiva infrastruttura sottostante.
Il Serverless è un approccio particolarmente utile a sgravare gli sviluppatori dalla maggior parte del lavoro pesante, come l’allocazione dello spazio di archiviazione e la creazione delle policy di networking. Tutte le attività di routine per il provisioning, la manutenzione e la scalabilità dell’infrastruttura sono demandate ad un service cloud provider. Le risorse “server” di cui le applicazioni necessitano vengono create e allocate in modo automatico, mentre il codice viene creato in pacchetti ed inserito all’interno del container stesso per il deployment.
Purtroppo, anche il Serverless ha i suoi difetti: impone infatti agli sviluppatori di ripensare al modo attraverso cui creano le applicazioni. Il suo approccio così differente rispetto agli altri metodi tradizionali comporta una formazione e uno studio accurato che spesso è specifico per cloud provider. Un esempio di serverless lo si può trovare applicato in quelle che sono le Lambda Function di AWS.
Ricapitolando: dalle VM, passando per i Container, fino al Serverless
Possiamo dire che, fino ad oggi, l’evoluzione tra questi approcci ha avuto un orientamento specifico alla semplificazione e all’automazione:
- dalle VM ai container: l’utilizzo dei container ha semplificato la distribuzione e la gestione delle applicazioni, rendendo più efficiente l'utilizzo delle risorse e aumentando la scalabilità;
- dai container al serverless: Le soluzioni serverless hanno ulteriormente semplificato la gestione delle applicazioni, eliminando la necessità di gestire l'infrastruttura sottostante, consentendo agli sviluppatori di concentrarsi solo sul codice.
Tuttavia, in questa evoluzione, un elemento che merita di essere evidenziato e di spiccare, è sicuramente Kubernetes.
Kubernetes è, di fatto, la “piattaforma” di orchestrazione attualmente più avanzata e permette la gestione di tutte le casistiche appena citate. Esistono infatti, progetti come KubeVirt che permettono di orchestrare VM all'interno di Container e progetti come Knative, che consentono di utilizzare K8S come piattaforma Serverless.
Chiaramente, in questo “diagramma evolutivo”, Kubernetes si pone, dal punto di vista dello sviluppatore di applicazioni, come l’ultimo atto che incorpora in sé tutti i vantaggi dei punti precedenti ma aggiunge uno svantaggio legato alla complessità di gestione, che integra a sua volta tematiche legate al DevOps e alla necessità di affidarsi a figure più DevOps Oriented.
Cosa sceglieresti tra VM, Container e Serverless?
La risposta dovrebbe essere: "Dipende dall’applicazione".
Ciascuna di queste opzioni ha il suo scopo e le sue limitazioni. Per questo la scelta tra VM, container e Serverless dipenderà dalle esigenze specifiche dell'applicazione e delle operazioni di sviluppo e gestione. Spesso, un approccio ibrido che sfrutta ciascuna di queste tecnologie in base alle esigenze può essere la soluzione migliore per un'organizzazione.
