A che punto è la virtualizzazione tra container e virtual machine

La virtualizzazione è la forma di esecuzione delle applicazioni che va per la maggiore nei datacenter e in particolare nel mondo cloud, ma anche nelle infrastrutture IT di un numero molto ampio di imprese.

D’altronde la comodità di una IT “elastica” è innegabile: a seconda del variare del carico di lavoro un’impresa può attivare e disattivare nuove macchine virtuali – quindi in pratica nuovi server – che lo gestiscono in maniera dinamica.

Questo approccio alla virtualizzazione – detto tecnicamente anche di full virtualization – è nato anni fa e si è diffuso velocemente in vari ambiti, tanto che oggi è anche possibile installare piattaforme di virtualizzazione su singoli PC e far convivere su di essi sistemi operativi differenti.

La peculiarità della full virtualization è infatti che la singola macchina virtuale è un “mondo” completamente separato dalle altre e autonomo. Quando si attiva si viene a definire la controparte virtuale di un server fisico, quindi con tutte le sue risorse (processori, storage, connessioni di rete, sistema operativo) che vengono “mappate” in maniera trasparente sulle risorse fisiche che l’hardware sottostante può mettere a disposizione.

L’applicazione eseguita da una macchina virtuale non “vede” nessuna differenza tra l’ambiente virtuale in cui si trova e un vero server fisico. A garantire la totale trasparenza di questa emulazione è l’hypervisor, uno stato software che si occupa di attivare e disattivare le macchine virtuali secondo necessità e che “traduce” le chiamate delle applicazioni alle funzioni e alle risorse del loro sistema operativo in altre chiamate alle risorse fisiche effettivamente disponibili. A seconda dei prodotti e degli approcci adottati per la virtualizzazione, un hypervisor è eseguito direttamente dall’hardware del server fisico o da un sistema operativo convenzionale.

Alla ricerca della leggerezza

In molti ambiti il concetto di attivare tutto un server virtuale quando serve è perfettamente adeguato. Lo è anche in altri settori – come lo sviluppo software o il test delle applicazioni – in cui il punto non è tanto creare una infrastruttura dinamica quanto ambienti completamente separati fra loro. La full virtualization consente ad esempio di avere la convivenza di più macchine virtuali basate su sistemi operativi del tutto diversi.

In altri casi però le macchine virtuali sono considerate un approccio eccessivamente pesante. L’alternativa sono i container, una forma di virtualizzazione a livello del sistema operativo che si è diffusa più di recente e che sta avendo grande successo soprattutto perché una gran parte dei servizi cloud va in questa direzione. Un container si può ancora considerare come un server virtualizzato ma solo per lo spazio utente, ossia la parte virtualizzata è l’ambiente di esecuzione delle applicazioni e non tutti i componenti sottostanti (dal sistema operativo in giù verso l’hardware). Il sistema operativo è quindi “vero” e comune a tutti i container.

In questo approccio non esiste l’hypervisor ma è presente un sistema che “impacchetta” le applicazioni (più in generale i servizi applicativi) in container, gestisce l’attivazione e disattivazione dei container stessi e crea un livello di astrazione fra questi e il sistema operativo ospitante.

Ci sono molti sistemi di questo genere ma quello che oggi va per la maggiore è certamente Docker, che ha anche il vantaggio di essere una piattaforma open source ampiamente supportata.

Il grande punto di forza dei container è che sono molto più “leggeri” delle macchine virtuali perché non devono attivare un loro sistema operativo dedicato. Sono così molto più veloci da attivare e disattivare, quindi più indicati per quegli ambienti in cui il carico di elaborazione varia sensibilmente e in maniera non prevedibile a priori.

Tutti i servizi erogabili via Internet ricadono in questa categoria e questo spiega la popolarità dei container: sempre più applicazioni sono oggi progettate come una collezione di micro-servizi online che dialogano fra loro, virtualizzarli attraverso i container è una scelta logica.

A ciascuno la sua virtualizzazione

Ma macchine virtuali e container non sono due opzioni antitetiche. Ciascuna ha le sue specificità e punti di forza e debolezza. La leggerezza dei container si paga ad esempio con l’impossibilità di avere container con sistemi operativi diversi (c’è solo quello che li attiva, in comune). Proprio avere il kernel del sistema operativo in comune è un altro potenziale punto debole dei container: in linea teorica un container potrebbe compromettere la stabilità del kernel stesso influenzando negativamente gli altri container.

A ciascuno, insomma, la sua soluzione. Tanto che nulla vieta, volendo e per avere la massima flessibilità, di attivare la virtualizzazione a container all’interno di una singola macchina virtuale che opera in autonomia dalle altre.