Per comprendere cos’è un software container, come funziona e perché venga visto non solo come mezzo abilitante lo sviluppo e delivery delle applicazioni composite, ma anche come valido sostituto delle macchine virtuali (la soluzione che oggi domina nell’I&O – infrastruttura e operazioni), ci si deve fare una domanda: perché virtualizzare un intero sistema quando se ne usa solo una parte? Una VM, lo dice il nome, è una macchina. Senza “ferro” ma completa d’ogni parte logica, con un sistema operativo che accede all’hardware tramite l’hypervisor, uno strato software che gestisce le istanze di tutte le VM che insistono sul server fisico. Ma un’applicazione, specie se è un semplice servizio come quelli che vanno a formare le nuove soluzioni, non ha bisogno di tutto questo.
Per cui si è cercato di creare un ambiente dove l’applicazione possa girare restando isolata dalle altre ma sfruttando direttamente, sia pur in modo condiviso, le risorse del server host tramite il kernel del sistema operativo del server stesso. Agli inizi l’idea si è sviluppata lavorando sulle doti native multi-user e multi-task di Unix, e da tempo infatti sia IBM AIX, sia Oracle Solaris offrono tecnologie del genere. Ma la vera innovazione dei software container è legata a Linux e al movimento open-source.
Nella nascita dei software container (SWC) Google ha avuto un ruolo determinante. Si deve infatti alla Casa di Mountain View se dal 2008 il kernel Linux di base comprende funzioni che abilitano sia controllo dell’hardware (cgroups) sia l’isolamento (spacename) necessari affinché ogni processo abbia una visione del sistema diversa dagli altri e si possano eseguire più applicazioni in una singola istanza all’OS Linux. Questi strumenti innalzano il livello di astrazione, che dall’hardware si porta al sistema operativo. Per cui sebbene nel container ci sia solo il codice sorgente con le binary-libraries, l’applicazione vede le risorse di sistema (file system, cpu, ram, disk I/O…) come se fossero interamente dedicate alla sua esecuzione.
Dai Linux Container a Docker e oltre
Chiunque usi Linux può quindi usare dei container (Linux container Lxc), e ciò da anni. Perché allora se ne parla tanto adesso? Perché se i container non sono una novità, lo è invece Docker, che, un po’ come ha fatto VMware per le VM, ne sta facendo decollare l’adozione esaltandone le doti e rendendone pratico l’uso.
Nato e tuttora gestito come progetto open-source, il software Docker, creato nel 2013 e dal giugno 2014 disponibile come release commerciale supportata dall’omonima società, automatizza il deployment delle applicazioni nei container e ne facilita la gestione. Al suo sviluppo, sostenuto prima da Red Hat e poi da Microsoft, Oracle e dalla stessa VMware, contribuiscono sia cloud provider (Google ovviamente, e Amazon, Azure, eBay, Spotify…), sia vendor come IBM, HPE, Dell-EMC, NetApp e tanti altri. Questa confluenza tra fornitori leader in hardware, software e servizi sta generando un’offerta vivacissima di strumenti e plug-in per controllare il versioning e la condivisione, creare repository, fare auditing e anche per usare gli SWC con database e infrastrutture proprietarie.
Ma proprio il successo dei container spinto da Docker ha mostrato i limiti dello strumento nel governo dei carichi di lavoro al crescere del numero di host e di SWC ospitati. Ancora Google, i cui servizi sono tutti in SWC, ha proposto Kubernetes (“timoniere”, in greco), un “orchestratore” che opera sui container gestibili con Docker sfruttando due nuovi concetti. Uno è il pod, un gruppo di SWC che viene dispiegato insieme su uno stesso host. L’altro è il label, un’etichetta che marca gli attributi del pod, come l’appartenenza a un nodo di calcolo, facilitandone l’organizzazione. Kubernetes ha attirato l’interesse della comunità open-source, che vi si è molto impegnata, e Docker vi ha risposto con Swarm, un tool che usa analoghi modelli di clustering e gestione per gruppi di container. Difficile dire oggi quale sarà l’orchestratore vincente, se mai ve ne sarà uno.
Quanto costa adottare i software container? Se il software Docker di base è gratuito, si pagano i suoi tool di servizio e quelli forniti dai partner, indispensabili per usare gli SWC in azienda. Stante i molti tipi d’implementazione e la turbolenza del mercato, fare un’analisi economica è praticamente impossibile. Possiamo però dire che a parità di servizi erogati nell’unità di tempo, analisti e blogger concordano nel definire il costo d’una struttura su SWC molto inferiore rispetto ad una su VM e hypervisor.
Software container e VM: insieme o contro?
Premesso che nel considerare le differenze tra SWC e VM dal punto di vista dei vantaggi per l’It e il business intendiamo SWC ‘Docker-capable’ integrati dei soli tool necessari nelle singole situazioni, il primo vantaggio di un SWC rispetto a una VM sta nella leggerezza. Non avendo un proprio sistema operativo, il peso di un SWC è solo di qualche decina di Mb contro i gigabyte di una VM. Ciò significa minor richiesta di potenza di calcolo (basta un laptop per ospitare centinaia di container) e maggiore velocità, non avendo l’overhead dell’hypervisor. I servizi containerizzati sono quindi disponibili in una frazione di secondo per essere eseguiti oppure aggiunti, rimossi o aggiornati nell’applicazione; ciò facilita la gestione dei cicli di rilascio e si riflette sulla customer experience, specie nel mobile, dove la velocità di risposta è basilare. Queste doti permettono anche di spalmare l’applicazione su un gran numero di micro-servizi, con un controllo più granulare della sua eseguibilità e un migliore sfruttamento delle risorse di sistema. Infine, chiudere i servizi in componenti distribuibili e configurabili con un sola riga di comando, senza badare all’ambiente runtime, accelera di molto il rilascio di applicazioni complesse, attuando efficacemente le pratiche DevOps. In effetti, chi punta al DevOps di regola opta anche per gli SWC. Questi vantaggi riguardano soprattutto lo sviluppo e deployment applicativo nei suoi effetti sul business. Ma gli SWC sono una soluzione anche per l’I&O (infrastruttura e operazioni) grazie alla loro portabilità. Facendo a meno di hypervisor proprietari, le comunità open-source e Docker hanno sviluppato un formato interoperabile che permette di eseguire i servizi in container su host eterogenei. Non occorre dire cosa ciò significhi in un ambiente cloud pubblico o ibrido: in pratica i carichi di lavoro si possono spostare sulla piattaforma che al momento, per prestazioni o per economicità, risulta più conveniente. Senza dover restare legati a un dato provider per le peculiarità della sua o della nostra tecnologia.
Ma vi sono punti in cui ‘vincono’ le macchine virtuali? Sì, almeno due: uno è la sicurezza operativa e la resilienza infrastrutturale data da tecnologie più che collaudate; l’altro è il supporto dei vendor VM alle applicazioni di back-end. Non sono cose da poco e infatti l’opinione corrente è che SWC e VM andranno a convivere dividendosi le aree d’impiego tra il front-end, web e mobile, e appunto il back-end. Tanto più che va detto che solo se occorrono le massime prestazioni un SWC è implementato “bare-metal”, ma di solito il suo server “fisico” è in realtà una macchina virtuale.
