La containerization architecture è un approccio moderno alla creazione di infrastrutture digitali delle imprese, che permette di realizzare pacchetti software completi, compresi di tutte le dipendenze, trasferibili come singole unità chiamati container.

Un container può essere messo in funzione virtualmente in qualunque ambiente host con tempi ridotti e procedure semplificate, a differenza dei tipici applicativi monolitici dove le migrazioni richiedono spesso complesse preparazioni preliminari e comportano un concreto rischio di risultare incompatibili con differenti hardware o infrastrutture, incontrando problemi di funzionamento difficili da prevedere e risolvere.

Che cosa sono container e orchestratori

I container possono essere concepiti come contenitori logici, che incapsulano un software in un singolo file eseguibile. Tale pacchetto richiede poi un motore di esecuzione per il sistema host, detto runtime, che si fa carico di fare funzionare in modo isolato e protetto tutti i singoli pacchetti containerizzati richiesti dall’infrastruttura informatica.

In una containerization architecture, ciascun software può comprendere tutto (e solo) il necessario al proprio funzionamento, per esempio file binari, librerie di codice, file di supporto e di configurazione chiamati manifest. Applicazioni o servizi containerizzati possono essere sottoposti a verifica come unit, poi essere distribuiti come file di immagine nel sistema operativo ospite.

Docker

La tecnologia di containerizzazione più diffusa e usata è certamente Docker, che ha reso efficiente e semplice l’uso di container Linux. Il progetto Docker, distribuito con licenza open source sin dalla sua nascita nel 2013, ha visto una diffusione notevole nel mondo delle soluzioni IT, agevolata dal sostegno sia da parte di molti service provider internazionali sia da parte di rivenditori di soluzioni hardware e software.

Il Docker engine, ovvero il modulo runtime cuore del sistema container, è stato realizzato per funzionare sia in sistemi Windows Server sia su varie piattaforme Linux, come per esempio CentOS, Debian, Fedora, Oracle Linux, Ubuntu, SUSE e RHEL.

Kubernetes, il ruolo degli orchestratori

Come strumenti di supporto, per agevolare le operazioni necessarie in una architettura a container, sono stati ideati software chiamati orchestratori. Il più diffuso e utilizzato è sicuramente Kubernetes, anch’esso un progetto open source (inizialmente sviluppato da Google), che permette di semplificare notevolmente il processo di migrazione, tra server differenti oppure tra tecnologie on-premise e legacy verso risorse cloud.

Kubernetes può operare non solo con Docker, ma anche con altre tecnologie container presenti e future, ovvero tutte quelle che aderiscono allo standard Open Container Initiative o OCI. Il suo utilizzo permette di eliminare molti dei processi manuali di configurazione per distribuire e scalare soluzioni containerizzate, soprattutto quando è necessario operare con cluster di host in cloud di vario genere (pubblici, privati o ibridi) ed è adeguato anche per gestire soluzioni cloud native.

Kubernetes consente letteralmente di “orchestrare” la struttura a container automatizzando la distribuzione e la gestione delle applicazioni containerizzate, verificando e gestendo vari parametri come la scalabilità, la resilienza e il failover dell’applicazione. I processi di preparazione e deploy possono essere riutilizzati ogni volta che occorrono, talvolta senza apportare modifiche, con evidente vantaggio di tempo e riducendo notevolmente i rischi di errori insiti nelle operazioni totalmente manuali.

Differenze tra container e macchine virtuali

Un’architettura basata sull’isolamento e sulla suddivisione del software in pacchetti, trasportabili in modo affidabile e semplice, si può basare non solo sui container, ma anche sui virtualizzatori. Sono tecnologie esistenti sul mercato da molto tempo, perciò risultano note e già utilizzate sia nelle grandi imprese sia dalle piccole società e dai privati. Perciò occorre chiarire alcune differenze importanti tra virtual machine (VM) e containerization architecture.

L’aspetto più importante è che un container richiede meno risorse ed è più veloce da preparare e distribuire. Infatti, implementare una macchina virtuale per eseguire il software significa in realtà preparare e trasferire ogni volta un intero sistema operativo, che funzionerà in parallelo a quello ospite. Invece, ogni pacchetto container può usare un solo sistema operativo condividendone le risorse con altri container e software. In termini quantitativi, se una VM può occupare gigabyte sommando sistema operativo e software, un container, che incapsuli soltanto il software dalle funzioni equivalenti, spesso può essere distribuito usando file di soltanto pochi megabyte.

Naturalmente un pacchetto containerizzato risulta più leggero di una macchina virtuale, ovvero richiede meno risorse e tempi di avvio ridotti. In un sistema ospite possono perciò essere utilizzati anche parecchi container allo stesso tempo, pur usando nel complesso minori risorse del sistema ospite rispetto a una singola macchina virtuale completa.

Una caratteristica importante condivisa con i virtualizzatori consiste nella stabilità complessiva del sistema ospite grazie all’incapsulamento in unità isolate dei vari software in esecuzione simultaneamente. Un malfunzionamento del singolo pacchetto non inficia né il funzionamento del server host né degli altri container, secondo il criterio del massimo isolamento. Risulta però generalmente più veloce individuare e risolvere un problema analizzando un singolo piccolo pacchetto rispetto a una intera macchina virtuale.

Vantaggi della containerization architecture

A un livello di astrazione elevato, la containerization architecture può essere considerata una struttura logica che permette di rendere autonomi e ben delimitati i singoli processi degli applicativi, anche se di grandi dimensioni. Ne consegue un concreto vantaggio in termini di velocità operativa e affidabilità quando occorre pianificare implementazione e trasferimento di applicazioni e servizi tra i server, per esempio quando occorre eseguire la migrazione tra sistemi hardware on premise verso il cloud.

Nelle moderne soluzioni IT che sono sempre più spesso implementate come microservizi, ovvero singole unità di dimensioni contenute che svolgono un compito specializzato all’interno di applicativi complessi, una struttura a container si integra in modo ottimale per offrire un controllo granulare preciso sia dal punto di vista della pianificazione e definizione strutturale della soluzione informatica, sia a un livello più basso per ottimizzare lo sfruttamento delle risorse di sistema.

Un singolo microservizio può funzionare all’interno di un container dialogando con gli altri che compongono la soluzione tramite librerie API standardizzate. I vantaggi sono notevoli in termini di isolamento, duttilità, portabilità, velocità di esecuzione e controllo dell’operatività durante l’intero ciclo di sviluppo e messa in opera dell’applicazione, sia dal punto di vista degli sviluppatori, sia dal punto di vista dei responsabili IT che devono pianificare implementazione, evoluzione e i costi di sviluppo e aggiornamento del sistema.

Un vantaggio pratico evidente nella containerization architecture è che l’aggiornamento e la manutenzione vanno eseguiti su un solo sistema operativo host, dato che ciascun container ne usa una propria istanza virtualizzata. Il beneficio nelle pratiche CI/CD è che si possono preparare e distribuire immagini software aggiornate con maggior frequenza e in un tempo sensibilmente minore.

Non va trascurato che per ogni server privato occorre acquistare una sola licenza del sistema operativo, anche nel caso di aggiornamenti futuri, poiché tutti i pacchetti containerizzati condividono le sue risorse, a differenza delle macchine virtuali, dove ogni sistema operativo commerciale e altri software di supporto necessari richiedono ovviamente l’acquisto di una licenza separata.

Chiunque adotti pratiche DevOps per velocizzare sia lo sviluppo sia il deploy delle applicazioni sceglie necessariamente sempre più spesso l’uso di una architettura a container perché, adottando un formato open source non proprietario, è prevedibile una migliore portabilità dei servizi su host eterogenei, siano essi già disponibili oppure nell’ottica di una futura evoluzione del software, per esempio per il trasferimento nel cloud dell’infrastruttura informatica.

L’uso di una containerization architecture permette di condividere, spostare e bilanciare i carichi di lavoro tra varie piattaforme seguendo l’evoluzione delle esigenze e delle tecnologie, evitando al contempo il fatidico lock-in, ovvero la necessità di restare legati a un service provider per il costo eccessivo in termini di tempo e lavoro necessari al trasferimento verso un altro fornitore. Nell’adozione della containerization architecture, l’affiancamento di un partner con competenze certificate e comprovata esperienza può essere decisiva per massimizzare i benefici di questo approccio, accelerando altresì l’innovazione in azienda.