Containerizzazione delle applicazioni

La containerizzazione si diffonde con Docker tra il 2012 e il 2013. Da allora, i container rendono più facile e sicura la portabilità delle applicazioni e l’attività di deployment. Approfondiamo gli aspetti più importanti che ruotano attorno al concetto di container e cerchiamo di dare una risposta ad una domanda: i container rappresentano il futuro?

Che cos'è la containerizzazione?

Possiamo definire un container come un contenitore virtuale. Una struttura logica che racchiude l’application code e tutti i componenti necessari al suo funzionamento. In questo modo il container può essere operativo su ambienti di esecuzione differenti ed essere così facilmente trasportato da un ambiente all’altro.

Per capire la containerizzazione bisogna fare un passo indietro. Il software tradizionale viene installato ed eseguito all'interno di una piattaforma che fornisce tutte le dipendenze necessarie alla nostra applicazione per poter essere eseguita. Le dipendenze di cui parliamo sono a loro volta software, in versioni di rilascio specifiche, che rendono la portabilità dell'insieme molto complessa. 

Se aggiungiamo all'equazione anche lo strato sottostante, ovvero il sistema operativo, che fornisce un metodo specifico di installazione del software, garantire il corretto funzionamento del codice diventa estremamente difficile, a prescindere dall'ambiente in cui esso viene eseguito. 

La logica dei container supera questi limiti. Nei container è contenuta l'intera applicazione impacchettata  (“packaging of software”), con tutte le componenti necessarie per il suo funzionamento: il codice binario dell'applicazione (o il codice che deve essere interpretato), le componenti del runtime cioè le librerie, le dipendenze, i file di configurazione e gli eventuali strumenti di sistema.

Così le containerized apps, e cioè le applicazioni incapsulate in container, possono essere spostate velocemente in altre piattaforme e infrastrutture bare metal o cloud. Di conseguenza, la containerizzazione permette di effettuare il deploy delle applicazioni in modo più semplice e rapido.

La nascita della containerizzazione

I container nascono come tentativo di "circoscrivere", cioè con obiettivi primari di sicurezza e stabilità. Alcuni anni fa si è cercato di separare le applicazioni o i carichi di lavoro dal resto del sistema, per ottenere una forma di "contenimento". 

Nei primi tentativi di approccio “a container” il kernel doveva ammettere l'esecuzione di istanze multiple dello "user space". Ciascuna istanza, separata dalle altre, costituiva un container isolato, dedicato a una singola applicazione o a un carico di lavoro.

I primi esempi di questo approccio sono stati le "jail" di FreeBSD e la partizione dei carichi di lavoro (workload partition) su AIX di Ibm. Sono state pensate numerose varianti (dai "virtual kernels" di DragonFly BSD ai "virtual private servers" di OpenVZ sino alle "zones" di Solaris), vincolate però a determinate architetture hardware e sistemi operativi, diversamente dai moderni container. 

Lidea dei container e delle containerized applications come li intendiamo oggi risale al 2013. I container vengono introdotti con la nascita di Docker, del suo Docker Engine e l'avvio della Open Container Initiative, creata sempre, tra gli altri, da Docker. Quest'ultimo progetto ha generato l’industry standard nel settore e ha permesso di utilizzare strumenti di containerizzazione diversi su piattaforme diverse, usando sempre gli stessi container.

Leggi anche: Cos'è l'orchestrazione dei container e come farla con Kubernetes

Containerization: quali sono i benefici?

Come abbiamo visto la containerizzazione di un’applicazione determina la sua esecuzione più efficiente e più rapida in ambienti diversi, migliorando i flussi di lavoro e la produttività. Vediamo nel dettaglio quali sono i vantaggi e le dirette conseguenze.

1. Portabilità e flessibilità delle applicazioni

Un container può essere spostato da una piattaforma all'altra senza problemi, perché porta con sé tutte le dipendenze necessarie alla sua esecuzione. 

Il fatto che possa essere scritto una sola volta ed eseguito in ambienti diversi senza bisogno di riconfigurarlo genera molte altre conseguenze positive. Permette, ad esempio, di avere lo stesso ambiente per lo sviluppo su un computer portatile e per l'esecuzione in un cluster in cloud. Questo garantisce anche che il comportamento dell’applicazione eseguita nel nostro ambiente di sviluppo locale sia identico anche negli ambienti di rilascio.
Ulteriore vantaggio è offerto da un vendor lock-in meno forte, in quanto la portabilità raggiunta permette di cambiare fornitore di infrastruttura cloud e spostare i propri carichi di lavoro senza dover riscrivere le applicazioni. 

In generale, con i container la flessibilità aumenta, la fase di deploy diventa più semplice e il rilascio e l'aggiornamento di applicazioni e prodotti software è più veloce. È possibile così trarre il massimo vantaggio dagli investimenti software, siano essi risorse esistenti o nuove possibilità offerte dal mercato.

2. Leggerezza

Un secondo beneficio dei container è la leggerezza, in particolare rispetto alle macchine virtuali tradizionali

A differenza di una virtual machine che contiene il proprio sistema operativo con tutte le complessità di manutenzione e pesantezze di esecuzione, il container sfrutta un approccio basato sulla condivisione dell’ OS kernel dello stesso sistema operativo host (tipicamente Linux). Può quindi contenere nient’altro che un'app e il proprio ambiente di esecuzione. 

Per questo, mentre le VM sono usate per architetture IT monolitiche e tradizionali e hanno dimensioni calcolate in gigabyte, i container - che tendono ad essere nettamente più contenuti - sono usati diversamente. Sono infatti compatibili con tecnologie DevOps, cloud e CI/CD. Questo concetto ci porta dritto al terzo beneficio.

3. Modernità e scalabilità

I container non sono solo leggeri e portabili, rappresentano anche una risposta adeguata ai paradigmi moderni di application development in ambito DevOps, per i sistemi serverless e i microservizi

I tempi di avvio sono minori. È possibile migliorare l'utilizzo della memoria e del processore sulla macchina fisica. L'ambiente di sviluppo è coerente con quello di produzione. Il supporto alle applicazioni Cloud Native è migliore. Tutto questo si traduce anche in una maggiore scalabilità orizzontale

In generale, i container sono ideali per la creazione di architetture di microservizi. Questo perché le microservice architecture possono essere implementate e dimensionate con una granularità maggiore rispetto a quelle delle applicazioni monolitiche tradizionali.

 

Prima di adottare K8s: leggi le best practice e gli errori da evitare!  Scarica il White Paper Guida all'adozione di Kubernetes

 

Containerization: quali sono le criticità?

Il principale svantaggio dei container deriva dalla relativa novità della tecnologia, che è costantemente in sviluppo. 

Nonostante dal 2013 l'adozione dei container abbia registrato una forte accelerazione e gli sviluppatori possano scegliere fra strumenti diversi su piattaforme diverse, ci sono spesso cambiamenti in corso e versioni meno stabili di altre

Questo vale soprattutto quando devono essere portate le tecnologie di containerizzazione su architetture di processori diversi. È il caso della migrazione ai processori con architettura Arm, per esempio, da quelli con architettura x86, che ha richiesto del tempo e ancora non è perfetta.

Un'altra forma di lock-in, dipende dai casi in cui debba essere containerizzata un’applicazione scritta per uno specifico sistema operativo, mentre i container impiegati in azienda utilizzano un altro sistema operativo. Tipicamente questo accade quando deve essere containerizzata un’applicazione Windows in un ambiente Linux (o viceversa, anche se è più raro). 

È possibile risolvere il problema aggiungendo uno strato di compatibilità, oppure usando un approccio come quello della "Nested virtual machine" (una VM contenuta in un'altra VM, che permette di utilizzare un diverso sistema operativo). Però si tratta di soluzioni che appesantiscono il lavoro del server fisico e aggiungono complessità.

Una tecnologia relativamente nuova, infine, richiede anche metodologie di lavoro nuove e competenze nuove, che richiedono tempo per diffondersi nel personale che lavora nel settore IT. Questo ritardo rende più difficile trovare amministratori di sistemi preparati.

Quali applicazioni sono adatte a essere messe in un container?

Applicazioni legacy

Il primo approccio alla containerization è quello di mettere in container le applicazioni legacy con l'obiettivo di modernizzarle. È il primo passaggio per la migrazione al cloud di sistemi che risiedono su server on-premises. 

In questo caso specifico, il vantaggio dei container non sta solo nella portabilità. Sta anche nella trasformazione delle applicazioni monolitiche in applicazioni con un’architettura basata su microservizi

Modernizzare le applicazioni legacy è quindi uno dei motivi per cui adottare la logica dei container. Come conseguenza l’ammodernamento non riguarderà solo le tecnologie (da monoliti su VM a microservizi su container). Con le containerized applications potranno essere adottate nuove metodologie di lavoro, passando dall’approccio waterfall ai più moderni Agile e DevOps.

Applicazioni eseguite in ambienti di cloud ibrido e multi cloud

Le aziende che vogliono operare su un mix di data center proprietario (on-premises) e uno o più cloud pubblici, hanno convenienza nel containerizzare le loro applicazioni. Grazie all’uso del container, le loro applicazioni possono essere eseguite in maniera coerente ovunque: dal laptop dello sviluppatore ai server on-premises agli ambienti cloud pubblici di fornitori diversi. 

Questa coerenza di esecuzione permette l'abilitazione di modelli di integrazione continua e deployment continuo (CI/CD), tipici degli ambienti di DevOps.

Applicazioni basate su un'architettura di microservizi

La creazione di nuove applicazioni basate su un'architettura di microservizi, in cui cioè l'applicazione è composta da molti, piccoli servizi fortemente disaccoppiati e implementabili in maniera indipendente, trova il suo naturale complemento nell'utilizzo dei container.

I container e i microservizi lavorano bene insieme perché containerizzare i microservizi vuol dire dar loro portabilità, compatibilità e scalabilità.

Perché i container sono il futuro?

Non esistono architetture e tecnologie "future-proof" in assoluto, ma solo relativamente. Fatta questa premessa, possiamo dire che i container sono il futuro? 

Sì, specialmente in contesti con un grado crescente di complessità. La containerization technology rappresenta una risorsa per affrontare le sfide future del panorama IT

Per concludere ripercorriamo le ragioni per cui containerizzare le applicazioni è una scelta che guarda al futuro:

  • I container hanno ormai sostituito in molti ambiti gli hypervisor e la virtualizzazione tradizionale. La loro portabilità, replicabilità, compatibilità e scalabilità li rendono lo strumento ideale per sfruttare al massimo i benefici del cloud computing, del cloud pubblico, degli ambienti ibridi e multi cloud.

  • I container sono ideali anche per lo sviluppo rapido di applicazioni on-premises che possano essere poi utilizzate su hardware diversi.

  • I container sono la tecnologia utilizzata per lo sviluppo di architetture basate sui microservizi, con modelli di sviluppo CI/CD e basati sull'approccio e la cultura DevOps e GitOps

  • Inoltre, i container sono la tecnologia giusta da prediligere per progetti di grandi dimensioni e con complessità crescente. Sono state progettate tecnologie e metodologie per dominare tale complessità. Una su tutte è l'orchestrazione dei container, che permette di gestire grandi volumi di container attraverso tutto il loro ciclo di vita.

  • Infine, i container sono una tecnologia moderna che ha raggiunto un buon grado di maturità e stabilità. Sono utilizzati sia per la modernizzazione di applicazioni legacy, che per la creazione di nuove applicazioni basate su paradigmi e architetture Cloud Native.

guida adozione kubernetes