Container e Virtual Machine: vantaggi e differenze di ognuno

Container vs Virtual Machine: vantaggi e differenze di ognuno. Container e virtual machine (VM) sono due argomenti IT che hanno acquisito una incredibile popolarità negli ultimi anni, contribuendo in maniera significativa al crescente successo del cloud computing, in particolare per quanto concerne il Platform-as-a-Service (PaaS), il mondo degli sviluppatori software.

Container e macchine virtuali hanno in comune il fatto di essere due tecnologie di virtualizzazione, ma proprio in questo aspetto emergono alcune differenze fondamentali, sia a livello tecnologico che a livello concettuale, ragion per cui vengono utilizzate in contesti anche piuttosto differenti tra loro.

In questo approfondimento ci soffermeremo soprattutto sulle principali caratteristiche di container e virtual machine per capire quali sono i contesti in cui potrebbe risultare più indicata una o l’altra soluzione, anche se si tratta, come vedremo, di opzioni tecnologiche tra loro assolutamente complementari.

Container vs Virtual Machine

Le macchine virtuali e soprattutto i container costituiscono due concetti tecnologici relativamente recenti, in quanto la loro popolarità, come annunciato, ha subito una notevole impennata grazie al cloud computing. Tuttavia, la virtualizzazione costituisce ormai un concetto “antico” nella storia dell’information technology.

Negli anni settanta IBM era già alla ricerca di soluzioni per effettuare test rapidi che non costringessero i suoi ingegneri a dover riconfigurare ogni volta i leggendari mainframe, questione estremamente esosa in termini di risorse. In fondo, si tratta di un concetto più che mai attuale ancora oggi, che è stato nel frattempo risolto dalla virtualizzazione, che in primo luogo rappresenta la capacità di astrarre risorse logiche per ottimizzare l’impiego delle risorse hardware.

Senza dilungarci in retrospettive di vario genere, è importante evidenziare come sia i container che le virtual machine siano tecnologie basate sulla virtualizzazione. Oltre ad appartenere a due differenti generazioni IT, derivano da una virtualizzazione su livelli differenti, per rispondere ad esigenze altrettanto differenti. Vediamole nel dettaglio.

Virtual Machine

Le virtual machine sono a tutti gli effetti ambienti virtuali che emulano le caratteristiche di una macchina fisica completa di hardware, sistema operativo e applicazioni. Grazie alla virtualizzazione è infatti possibile eseguire su un server fisico una o più macchine virtuali, grazie ad una tecnologia definita hypervisor o virtual machine monitor (VMM).

Esistono fondamentalmente due principali tipologie di hypervisor: di tipo 1 e di tipo 2.

L’hypervisor di tipo 1, altrimenti noto come bare metal, rappresenta un sistema operativo host e pertanto si posiziona subito sopra l’hardware del server fisico, senza prevedere ulteriori livelli intermedi. Il bare metal è particolarmente diffuso nei data center on-premise e in cloud, ad esempio per rendere disponibili i servizi IaaS (Infrastructure-as-a-Service).

L’hypervisor di tipo 2 si posiziona ad un livello superiore rispetto al bare metal. È infatti un software applicativo installato su un sistema operativo host. In questo modo è possibile avviare macchine virtuali su macchine Windows, Linux o MacOS dotato di sufficienti risorse hardware, eseguendo le VM direttamente dalla console del software hypervisor installato.

A prescindere dal livello in cui si posizionano, le virtual machine emulano un sistema hardware-software completo, dotato di CPU, GPU, memoria, storage, rete e di tutto quanto occorre per garantire un corretto funzionamento.

Ovviamente tali risorse non coincidono con le stesse della macchina fisica che le esegue, ma dalle condizioni definite dall’hypervisor durante il processo di creazione e configurazione della VM. Per questa ragione è possibile eseguire più macchine virtuali su un singolo server. Questo costituisce un aspetto fondamentale per il consolidamento dei server fisici, che possono essere sfruttati in maniera molto più intensiva rispetto al loro autonomo funzionamento o in relazione all’esecuzione di una singola macchina virtuale.

Una volta configurata nei suoi dettagli, una macchina virtuale può sostituire a tutti gli effetti un ambiente desktop tradizionale ed essere impiegato per qualsiasi tipo di applicazione, a condizione che la VM stessa ovviamente goda delle risorse necessarie per eseguire i carichi di lavoro previsti. Anche in questo caso, nessuna sostanziale differenza rispetto alla condizione in cui ci ritroveremmo a dover assemblare una macchina fisica.

Oltre al consolidamento, un aspetto che pende a favore delle virtual machine è costituito dalla sicurezza informatica. Anche se molti non apprezzano questa definizione, ci sentiamo di affermare con relativa certezza che le VM siano più sicure per design rispetto alle macchine fisiche. Risulta infatti piuttosto difficile smentire il fatto che la loro esecuzione avvenga in maniera isolata rispetto ai sistemi host.

Se ci ponessimo nella condizione di subire un incidente di sicurezza informatica, per risolvere il problema è spesso sufficiente chiudere e riavviare l’istanza di una VM, in quanto questa rimane isolata rispetto al server fisico che ne consente l’esecuzione. In questa configurazione è pertanto ben più semplice limitare il propagarsi dell’infezione in un ambiente che richiederebbe un’operazione di ripristino ben più gravosa in termini di tempo e risorse per rimediare i downtime causati dall’incidente stesso, con tutto ciò che ne consegue.

Container

Offrire una definizione generica di container è davvero semplice, dal fatto che sono dei contenitori virtuali che consentono di eseguire un’applicazione. Il nostro lavoro sarebbe decisamente meno semplice se dovessimo divulgarne la complessità che ne consente il funzionamento. Del resto un minimalismo di facciata nasconde sempre un’architettura piuttosto articolata. In questo contesto, l’IT ovviamente presenta rare eccezioni alla regola, ma quanto ci preme evidenziare in questa sede è come l’obiettivo delle applicazioni sia sempre più orientato ad automatizzare e rendere disponibile con logiche self-service il software necessario all’utente finale per svolgere il proprio lavoro. Il tutto senza doversi preoccupare minimamente dell’infrastruttura IT che ne consente il funzionamento.

Per tale ragione, i container costituiscono un ambiente di esecuzione ideale per i microservizi che compongono le applicazioni moderne, capaci di ridefinire il tradizionale concetto di architettura monolitica del software. I container sono strumenti che agevolano lo sviluppo del software in tutte le sue fasi, grazie all’impiego di metodologie come DevOps.

La crescente diffusione delle applicazioni cloud native, derivante in gran parte dalla migrazione in cloud delle applicazioni legacy, ha consentito agli sviluppatori di apprezzare in misura crescente le qualità dei container Linux e di tutte le tecnologie annesse alla loro creazione e orchestrazione, come Docker e Kubernetes.

I container costituiscono ambienti di runtime per i microservizi, in grado di mettere a disposizione dello sviluppatore ciò che occorre per la loro corretta esecuzione (librerie, file eseguibili, dipendenze, file di configurazione, codice binario, ecc.) nell’intero ciclo di vita. In particolare ciò vale per quanto concerne il test e il deploy delle applicazioni, vista la frequenza con cui vengono svolti nei cicli CI / CD che costituiscono il modello di distribuzione del sempre più diffuso Software-as-a-Service (SaaS).

Le differenze

A livello IT, la prima differenza che salta all’occhio tra cointainer e virtual machine è il livello a cui avviene il processo di virtualizzazione che le genera. Le VM sono virtualizzate a livello hardware e mettono a disposizione dell’utente tutto ciò che può essere reso disponibile al di sopra di tale livello. I container invece costituiscono una virtualizzazione al livello del sistema operativo, per cui risultano notevolmente più leggeri, dal momento che le loro immagini non contengono tutta la parte hardware. Questo spiega le differenze dimensionali che spesso intercorrono tra gli elementi delle due tecnologie, che spaziano da alcuni mega nel caso dei container a diversi giga nel caso delle virtual machine.

Ma a parte questi dettagli, che possono essere più o meno rilevanti in termini di gestione, dalle descrizioni che abbiamo effettuano nei precedenti paragrafi appare evidente come container e virtual machine siano contraddistinte da differenze che derivano dal fatto di essere nate per risolvere esigenze pratiche totalmente diverse.

Ciò spiega perché il container ha la sola finalità di costituire l’ambiente di esecuzione per un componente di un’applicazione complessa, mentre la virtual machine ha quale obiettivo quello di mettere a disposizione dell’utente un intero sistema, che comprende ovviamente anche un intero sistema operativo e tutte le applicazioni complete che vengono ritenute necessarie per svolgere un’ampia gamma di carichi di lavoro.

L’impiego di una macchina virtuale non esclude l’utilizzo di un container, e viceversa, in quanto si tratta di tecnologie assolutamente complementari. Una macchina virtuale può essere utilizzata per eseguire dei container, così come è possibile scegliere un approccio decisamente agli antipodi. In questo caso, potremmo addirittura dimenticarci di tutta l’infrastruttura hardware /software, utilizzando, ove possibile, il modello serverless, con container stateless che prevedono funzioni strettamente legate agli eventi che danno luogo alla loro esecuzione. Per tali ragioni, il serverless costituisce la manifestazione più “dura e pura” del modello “pay per use”, che costituisce da sempre una delle principali ragioni del successo del cloud computing rispetto all’IT on-premise tradizionale.

Quale soluzione utilizzare?

Prima di dare una risposta a questa domanda ha tutto il senso chiedersi in quale contesto IT questa domanda abbia veramente senso, in quanto la risposta potrebbe essere molto meno scontata rispetto a quanto ci si potrebbe attendere.

Abbiamo più volte accennato al fatto che i container costituiscano la condizione ottimale per eseguire l’istanza di un’applicazione. Infatti questa è la ragione per cui sono stati creati. Tuttavia, tale operazione potrebbe essere eseguita anche configurando ad ok l’istanza di una macchina virtuale. Una volta in esecuzione, non vi sarebbero sostanziali differenze, ma le due opzioni presenterebbero un dispiego di risorse eccessivamente sbilanciato, in quanto la VM deve virtualizzare anche l’intero hardware e il sistema operativo su cui è sua volta virtualizzato il container stesso.

Nell’ambito dello sviluppo software basato su architettura a microservizi, i container costituiscono la condizione preferenziale, ma al tempo stesso si collocano molto più in alto rispetto al kernel del server sottostante. Questo potrebbe costituire in un certo senso un limite in termini di compatibilità e portabilità. Tecnologie come Docker consentono di ovviare piuttosto facilmente a questa sfavorevole condizione rispetto alla configurazione di un’intera virtual machine, anche se ovviamente comportano competenze addizionali per il loro efficiente impiego.

Laddove il container si distingue per la sua agilità nella creazione e nell’esecuzione delle istanze dei microservizi, le virtual machine spiccano per la loro flessibilità nel coprire la quasi totalità delle situazioni possibili. Per questa ragione le VM risultano maggiormente indicate per gestire applicazioni che richiedono condizioni più esose e complesse rispetto a quelle per cui tradizionalmente si opta per la leggerezza operativa dei container.

In ogni caso, lo ribadiremo fino allo sfinimento, non si tratta di scegliere tra VM e container. Il nocciolo della questione risiede nel comprendere come sfruttare al meglio le rispettive caratteristiche per configurazione un’infrastruttura IT capace di soddisfare tutti i carichi di lavoro con un dispendio ottimale in termini di risorse, senza perdere mai di vista la scalabilità, ragion per cui i cloud computing spesso e volentieri costituisce la miglior alternativa disponibile per godere di queste tecnologie al pieno delle loro potenzialità.