Verso la fine degli anni ’90 si è compreso e si è iniziato a sfruttare in modo esteso (perché la virtualizzazione nasce ancora prima) i software in grado di astrarre le componenti hardware di client e server – risorse fisiche reali (Cpu, schede di rete, storage, Gpu) – rendendole disponibili come risorse virtuali, cioè a livello logico in macchine virtuali.
Questo rende possibile, su un’unico sistema di computing e senza bisogno di gestire “fisicamente” le risorse di storage, per esempio, di far girare sistemi operativi diversi, semplicemente “accendendo” una macchina virtuale su cui è possibile installare un sistema operativo scelto, indipendentemente da quello nativo e le relative applicazioni scritte per quel sistema operativo.
L’utente finale guadagna così la disponibilità di ambienti diversi (emulazione di piattaforma) con la stessa facilità con cui si apre su un computer una nuova applicazione, in una nuova finestra, e di farlo senza riavviare il computer/server e senza dedicare risorse fisiche specifiche ad ognuno dei sistemi operativi.
Un vantaggio relativo in ambienti client, fondamentale invece per il mondo dei server (ma anche dei mainframe), per esempio perché questo ha reso possibile anche dividere tra più utenti l’uso di una singola risorsa.
Il “motore” che rende possibile questa suddivisione di risorse è denominato hypervisor (o anche VM monitor). Le macchine virtuali (VM) restano ambienti isolate e le risorse sono condivise a seconda di come è stabilito a livello software. Con l‘hypervisor ad offrire ai diversi ambienti quanto serve per fare girare bene quelle applicazioni.
Quelli portati dalla virtualizzazione “tradizionale” sono vantaggi fondamentali alla base della nascita del cloud computing, perché le virtual machine hanno permesso e permettono di “consolidare” il parco di installato, per esempio riducendo il numero dei server che servono per fare girare le applicazioni, anche quando dovrebbero sfruttare sistemi operativi diversi. Questo proprio perché più macchine virtuali possono girare nello stesso tempo, sfruttando le risorse assegnate, su un unico sistema fisico. Per tutto questo oggi è davvero senza alcun senso pensare ad una singola applicazione, per quanto impegnativa, in esecuzione solitaria su un server.
Perché in cloud le VM non bastano
Proprio il cloud computing però ha portato all’esigenza di alzare l’asticella proponendo nuove sfide. E’ anche relativamente facile infatti, nel contesto attuale, immaginare il limite della virtualizzazione come intesa fino ad oggi.
Ogni macchine virtuale prevede necessariamente di essere “abitata” da un sistema operativo completo, un’immagine di esso che incide sull’utilizzo della memoria e delle altre risorse. Non solo, questo determina anche uno spreco di risorse nelle diverse fasi di vita del software e di suo è facile immaginare che possa frenare proprio l’ideale scenario multicloud in cui spostare un’applicazione dovrebbe essere facile e veloce. Quanto sarebbe più comodo invece di virtualizzare tutto questo insieme di risorse, astrarre solamente quella parte di ambiente necessaria alle applicazioni per farle funzionare, con le istruzioni per farlo?
Il vantaggio dei container
E’ quello che succede con i container che è possibile definire come un sistema di virtualizzazione vera e propria del sistema operativo, non dell’hardware. Questo permette di far funzionare un’app in modo corretto anche quando viene spostata tra diverse VM. I container quindi si trovano ancora su un server fisico, sopra il quale funziona un OS, e condividono il kernel dell’OS sull’host in sola lettura e solo per le informazioni che servono, si avviano in modo molto veloce.
Ugualmente a come fanno le VM offrono uno spazio isolato di esecuzione pur sfruttando l’hardware condiviso. Allo stesso tempo proprio come accadde per la virtualizzazione con VM, questa sorta di “virtualizzazione al quadrato” riduce ulteriormente i costi perché i container condividono un unico sistema operativo (si deve quindi provvedere al buon funzionamento non di “enne” macchine accese ognuna con un OS).
Non solo, attraverso i container è possibile gestire in modo granulare le risorse di calcolo – da qui i cosiddetti microservizi. Spieghiamo: invece di pacchettizzare in senso logico un’app (astratta rispetto all’ambiente in cui è eseguita) è infatti possibile containerizzare anche solo un servizio di questa. In questo modo è possibile agli sviluppatori suddividere ulteriormente le risorse in microservizi, a vantaggio della fluidità di esecuzione delle applicazioni.
In estrema sintesi, ma pensiamo del tutto comprensibile, mentre con una macchina virtuale è l’hardware ad essere virtualizzato per eseguire più istanze anche di sistemi operativi diversi, i contenitori offrono la possibilità di virtualizzare un OS e su un’unica istanza farvi girare sopra, in ambienti isolati, diversi servizi. La velocità, l’agilità e la portabilità dei container li rendono poi un ulteriore strumento per semplificare lo sviluppo del software.
Al posto dell’hypervisor serve però sempre un “motore” che prepari il pacchetto di applicazioni/servizi necessari per funzionare l’applicazione finale in modo da generare il corrispettivo dell’astrazione hardware tra il container e l’OS che lo ospita. E’ chiaro invece che container diversi condividono nel loro funzionamento un unico sistema operativo, mentre sì, i processi delle applicazioni restano isolati.
In un’ottica Devops la containerizzazione offre anche un’ulteriore sequenza di vantaggi: chi sviluppa pensa alle dipendenze dell’applicazione, chi deve occuparsi di deployment non si preoccuperà più di dipendenze diverse da versione a versione – perché il container può includerle così come le versioni specifiche dei runtime dei linguaggi di programmazione e altre librerie software – tipicamente sfruttando per esempio sistemi come Docker e Kubernetes che forniscono il livello di astrazione necessario e rappresentano, per questo approccio i nuovi “motori”.
Non intendiamo assolutamente assimilare le due soluzioni. Mentre il primo infatti genera container e permette di distribuirli e poi eseguirli, Kubernetes permette anche di orchestrare Docker su nodi importanti per le operazioni di clustering. Per questo avrebbe forse senso, a volere, un confronto tra Kubernetes e Docker Swarm, che rappresenta la soluzione di clustering di Docker per i container Docker, nativamente integrata.
E mentre Docker è un software autonomo che può essere installato su qualsiasi computer per eseguire applicazioni in container, allo stesso tempo Kubernetes si qualifica come orchestratore
Uno sguardo al mercato, tra previsioni discordanti
Tutto bello e senza criticità? Non proprio. Il primo motivo è strettamente logico: innalzare al quadrato la virtualizzazione significa aumentare anche l’entropia. Spieghiamo: il numero dei container che insistono sullo stesso sistema operativo non è di poche unità. Pur pensando ad un ideale, le “chiamate” di un container al kernel dell’OS potrebbero causare dei disservizi che si possono riflettere anche su altri container. Il secondo è dato dalla complessità degli ambienti messi in gioco.
In primis, alcuni dei protagonisti del mercato public cloud, dopo non poco tempo di riflessione – quasi in ritardo rispetto a quanto chiesto dal mercato – finalmente investono nel supporto nativo per Kubernetes (che ha le origini in Google), anche per questo forse, per questi ritardi, il livello di complessità è ancora elevato.
Complessità tra l’altro che non sempre richiederebbe di essere indirizzata attraverso container, ma sarebbe risolvibile spesso sfruttando un ambiente nativo Paas ben organizzato, ma con un distinguo: ora è così… Pensiamo invece che in un vero scenario multicloud, la containerizzazione diventi indispensabile.
Non solo, un’infrastruttura efficace per le sperimentazioni con set di dati eterogenei, e l’utilizzo quindi di modelli di ML e AI, a nostro avviso necessariamente ne farà un alto utilizzo. Questo perché i container permettono una rapida distribuzione del codice in ambienti eterogenei. Anche gli analisti vedono questa come direzione di sviluppo.
Quello dei container è oggi un mercato che entro la fine dell’anno, secondo 451 Research varrà già 2,6 miliardi di dollari. Mentre gli analisti di Gartner segnalano che più del 70% delle aziende che operano a livello globale, entro il 2023, avrà in produzione almeno due applicazioni critiche, rispetto ad una percentuale di appena il 20% attuale.
© RIPRODUZIONE RISERVATA
