Application Container

Oggi tratteremo un argomento che probabilmente avrete già sentito: gli Application Container.

Nel mio precedente articolo, ho parlato delle tecnologie Serverless; qual’è il significato che si cela dietro questa parola e quali siano le implicazioni pratiche e le tecnologie a disposizione degli sviluppatori.

Questo articolo è stato pubblicato appositamente dopo quello sopracitato perchè, in base a quello che ritengono molti del settore, queste due tecnologie sembrano essere incompatibili: una (Docker) ha al centro la virtualizzazione in container, e pare essere sostituita dall’altra (Serverless) per certi versi maggiormente evoluta, che offre il totale disimpegno riguardo alla manutenzione di server.

La domanda che a molti può sorgere spontanea, potrebbe essere “Che senso ha trattare di una tecnologia superata?“.

Come per ogni tipologia di scienza, è necessario conoscere da dove derivano i paradigmi che impieghiamo attualmente al fine di utilizzarli con il miglior grado di efficacia ed efficienza possibile. Se questa risposta non dovesse essere sufficientemente motivante per andare avanti con la lettura, possiamo guardare anche ad una motivazione più pragmatica.

Sono convinto, infatti, che la domanda sia in un certo senso mal posta, dato che ritengo errato affermare che i container siano stati soppiantati dall’avvento di Serverless; si tratta infatti di tecnologie complementari e che sopperiscono ad esigenze diverse.

Antefatto sulla virtualizzazione

Dagli albori dello sviluppo del software, con il costante aumentare del numero di applicazioni di cui una singola azienda necessita ed il conseguente incremento di utilizzo di potenza computazionale, l’uomo è stato costretto al malaugurato compito della ricerca di nuove risorse: nuovi computer, nuovi server da inserire nel proprio business.

Questo, che oggi ci può sembrare un lavoro di poco conto, risultava essere realmente un compito dispendioso: ciò significava infatti andare soli o con un gruppo di persone a ritirare da un venditore magari uno scatolone di centinaia di chili pieno di circuiti elettrici e dischi magnetici, caricarlo su un furgone, trasportarlo alla sede aziendale, scaricarlo, portarlo, che so, al quarto piano ed installarlo.

Da questa problematica e dalla necessità di sistemi operativi diversi per far girare applicazioni di natura sempre più variegata, si sviluppa la tecnica della virtualizzazione; questa tecnica, benché negli anni 2000 abbia goduto di molto interesse (e goda tutt’ora in realtà…), ha origini ben più lontane, addirittura risalenti agli anni 60 con il System/370 della IBM. Esso, infatti, grazie a due componenti VM/CMS (VIRTUAL machine/conversational monitor syatem), offriva a più utenti una copia personale del sistema operativo.

Il grande cambiamento è arrivato però con la nascita di WMWare. Con la sua virtualizzazione “alla portata di tutti”, ha dato la possibilità alle aziende operanti nel settore informatico di acquistare macchine virtuali da aziende terze, che si facevano carico dell’onere del dimensionamento delle risorse hardware, della manutenzione e degli aggiornamenti.

La storia delle macchine virtuali è stata radiosa e tutt’ora queste sono al centro di reparti informatici di molte aziende. Essendo però l’uomo tendente naturalmente verso l’esplorazione e la scoperta di nuove frontiere, poco a poco ha sviluppato l’idea di poter ottenere di più dall’utilizzo del proprio hardware e dalla virtualizzazione.

Il principale limite che viene evidenziato in questa tecnologia è la necessità di ogni macchina virtuale di avere un proprio sistema operativo: ciò comporta infatti che ogni macchina virtuale necessiti di un surplus di risorse necessarie ai processi base del SO, dell’acquisto di una eventuale licenza e, non meno importante, di ordinaria amministrazione come aggiornamenti antivirus o patch.

Perché virtualizzare un intero sistema quando se ne usa solo una parte?

Cosa sono i Container?

Nella nascita dei software container, Google ha avuto un ruolo determinante.

Grazie agli sviluppi della Casa di Mountain View datati 2008, il kernel Linux di base comprende funzioni che abilitano sia al controllo dell’hardware (cgroups) sia all’isolamento (spacename). Condizioni sufficienti e necessarie affinché ogni processo abbia una visione del sistema diversa dagli altri e si possano eseguire più applicazioni del sistema operativo in una singola istanza.

Quindi è chiaro che negli ambienti Linux i container non sono una novità, ma allora perché solamente adesso sono al centro dell’attenzione?

Nel parlare della storia che ha portato all’esigenza di sviluppare sistemi di virtualizzazione più efficienti, ho accennato al rapporto tra le macchine virtuali (la loro espansione) e VMWare; con i container abbiamo osservato un processo similare.

Questa volta l’azienda scesa in campo si chiama Docker Inc (di cui parlerò in seguito).

I container invece di eseguire una virtualizzazione a livello hardware (come ad esempio fanno le macchine virtuali), ne effettuano una a livello di sistema operativo ed in modo che diversi container possano essere eseguiti direttamente sul kernel del sistema operativo.

In questo modo i container sono molto più leggeri: grazie alla condivisione del kernel col sistema operativo, permettono un avvio in tempi minimi ed utilizzano una frazione della memoria rispetto alle VM.

I container, pesando pochi MB, (rispetto alle macchine virtuali che arrivano a toccare svariati GB) sono particolarmente adatti alle situazioni in cui il carico di elaborazione da sostenere è variabile nel tempo ed ha picchi poco prevedibili. Questo è il principale motivo del passaggio dalle macchine virtuali ai container: l’assenza di sistemi operativi ridondanti in elaborazione sul medesimo hardware, richiedenti risorse per processi inutili alle esigenze del nostro software.

Si può quindi sostenere che i software container (da adesso in poi abbreviati con SWC) derivino soprattutto da un lavoro di ottimizzazione e di sfoltimento di tutto ciò che non è necessario agli scopi dei nostri applicativi.

Gli SWC hanno avuto un ulteriore incentivo: l’aumento dell’approccio di sviluppo a micro-servizi. Grazie al loro paradigma “a scatole nere”, con la possibilità di essere avviati o arrestati indipendentemente l’uno dall’altro, stimolano gli sviluppatori a limitare lo scope delle loro applicazioni e a prediligere più applicazioni piccole rispetto ad una monolitica (rispettando il primo principio SOLID).

Oltre a ciò possiedono un’ulteriore qualità che renderà felici gli stoici dell’informatica: i container funzionano ad immagini.

La tua applicazione o servizio, le relative dipendenze e la corrispondente configurazione, sono inclusi in uno stesso pacchetto sotto forma di immagine del contenitore; questo permette la distribuzione delle nostre applicazioni tra ambienti diversi con modifiche minime se non inesistenti.

Grazie ai container, nessuno sviluppatore può più permettersi di dire “Ma sulla mia macchina funzionava!”

(fonte https://www.docker.com/resources/what-container)

Cos’è Docker?

Docker è un progetto open source nato con lo scopo di automatizzare la distribuzione di applicazioni sotto forma di contenitori leggeri, portabili e autosufficienti che possono essere eseguiti su cloud o in locale. È sviluppato dall’omonima società Docker Inc. con sede a San Francisco, che attualmente è la più grande azienda nell’ambito dello sviluppo dei container.

Grazie a Docker il processo di distribuzione di un’applicazione si riduce quindi alla creazione di una immagine, contenente l’insieme dei dati di cui necessita un’applicazione per essere eseguita: librerie, altri eseguibili, rami del file system, file di configurazione, script, ecc.

Per capire la correlazione tra container e immagini (cito un esempio molto popolare in rete), si può pensare all’immagine come ad un negativo fotografico, che una volta sviluppato dà vita alla foto così come la conosciamo.

Docker utilizza le funzionalità di isolamento delle risorse del kernel Linux, come cgroups e namespaces, per consentire a container indipendenti di coesistere sulla stessa istanza di Linux.

Queste sono alcune caratteristiche base di un Docker container:

  1. I container possono essere stoppati senza incorrere ad alcuna perdita di dati in esso contenuti.
  2. Il riavvio del container porta ad un ripristino dei dati a prima dello stop dello stesso (come accendere e spegnere una macchina virtuale).
  3. Distruggendo un container si formattano anche i dati in esso contenuti.
  4. Qualora si siano salvati dei dati su un volume diverso quelli persisteranno.

La cosa maggiormente interessante di Docker è che esiste un intero ecosistema, una suite di tools, che facilita l’utilizzo dei container stessi.

Partendo dal Docker Hub, che è il più grande repository al mondo di immagini (ne esistono anche di terze parti ma non con la medesima offerta), lo Universal Control Panel, cioè una dashboard per il controllo dei container tramite interfaccia grafica, passando a Docker Swarm per la gestione di cluster di container e del loro scheduling ed arrivando infine a Docker Content Trust per garantire la sicurezza ed integrità delle informazioni scambiate, la varietà e la scelta di strumenti è veramente ampia.

Per una panoramica ancora più completa vi invito a visitare il sito ufficiale di Docker, dove troverete una sezione di documentazione apposita per gli strumenti di sviluppo.

Questo strumento è pronto per lo sviluppo in ambienti enterprise di produzione?

Qui sotto riporto l’offerta di Docker Inc. di versioni stabili utilizzabili commercialmente:

  1. Docker Engine versione 1.10 o superiore.
    • Versioni sperimentali (nightly)
    • Stabili (ogni 2 mesi)
    • Versioni con supporto commerciale ogni 6 mesi con contratti di assistenza.
  2. Docker Swarm (clustering) versione 1.0 o superiore.
  3. Docker content trust

Meglio Container o FAAS?

Alcuni, come si è detto, sostengono che il modello FaaS sostituirà completamente l’impiego dei container. Altri pensano che ne diminuiranno i casi d’uso. Ma è davvero inevitabile la mutua esclusione, o semplicemente possono essere utilizzati in contesti differenti?

Rispetto ai container, il paradigma Serverless è caratterizzato da una funzione più avanzata: mentre un container richiede almeno il setup della macchina in cui saranno ospitati gli SWC, nel caso di Serverless l’infrastruttura è totalmente gestita dal provider, per cui ci si limita al solo sviluppo e caricamento del codice sulla piattaforma.

Grazie a questa sua caratteristica, Serverless consente di creare ed eseguire applicazioni e servizi senza provisioning, ridimensionamento e gestione di server; in pratica si può creare qualsiasi tipo di applicazione o back-end preoccupandosi solamente della stesura del codice, senza nessuna conoscenza IT.

Potete trovare argomentazioni più esaurienti riguardo ai vantaggi di Serverless, nello specifico delle FAAS, nel mio precedente articolo, di cui vi propongo un riepilogo:

Pro e contro di Serverless

Vantaggi di Serverless

  1. Lo sviluppatore deve solamente caricare le funzioni. Non deve preoccuparsi dell’amministrazione del server.
  2. Dato che si paga per l’esecuzione della funzione, Serverless è (generalmente) più economico dei container.  Quando un’applicazione è inutilizzata, viene stoppata e non si paga per il tempo di inattività.
  3. Non c’è preoccupazione per la scalabilità in quanto il provider scelto se ne occupa in caso di necessità.
  4. L’aggiornamento o la modifica di una singola funzione è in genere più semplice da eseguire in un’architettura senza server rispetto a qualsiasi altra tecnologia.

Svantaggi di Serverless

  1. Perdita di controllo sull’architettura e la gestione delle risorse.
  2. A seconda del carico di lavoro, le architetture senza server possono non essere così vantaggiose economicamente. Con una errata analisi o sviluppo del software potrebbero risultate dispendiose.
  3. L’architettura senza server, essendo ancora una tecnologia in fase di affermazione, a volte può essere molto complicata da ottenere e potrebbe richiedere costi significativi per le risorse umane.

Pro e contro di Docker Containers

Vantaggi dei Docker Container

  1. I container Docker sono indipendenti dal fornitore e portatili per loro natura, mentre Serverless dipende sempre da terze parti.
  2. Consente agli sviluppatori di creare, testare e distribuire applicazioni rapidamente grazie alle dimensioni ridotte rispetto alle VM, poiché i soddisfano i requisiti strettamente necessari di runtime dell’applicazione.
  3. Piena flessibilità e controllo in termini di gestione delle risorse e sicurezza.
  4. Docker Inc. offre una grande quantità di tools molto evoluti per una gestione a tutto tondo dei containers.

Svantaggi dei contenitori Docker

  1. Necessita almeno del setup iniziale della macchina ospitante (host).
  2. Per impostazione predefinita, tutti i dati all’interno di un contenitore scompaiono quando il contenitore viene eliminato.
  3. I contenitori utilizzano le risorse in modo più efficiente rispetto alle macchine virtuali, ma sono comunque soggetti a sovraccarico di prestazioni a causa, ad esempio, dell’interfaccia tra il contenitore e il sistema host.
  4. Nonostante la piattaforma Docker sia open source, alcuni prodotti non sono completamente compatibili con altri. Ad esempio, OpenShift funziona solo con l’orchestrator Kubernetes.
  5. I container Docker sono stati progettati come soluzione per la distribuzione di applicazioni server che non richiedono un’interfaccia grafica. Una soluzione che prevede GUI può avere vita difficile all’interno di un container e questa potrebbe non risultare la strategia migliore.

Quando usare i Docker Container?

Serverless è la migliore soluzione per app che devono essere pronte ad eseguire attività, ma non devono sempre essere in esecuzione. È l’ideale, inoltre, quando la velocità di sviluppo e la minimizzazione dei costi sono fondamentali e se non si desidera gestire i problemi di ridimensionamento.

Esistono però casi in cui i container vincono rispetto all’assenza di server.

Un’applicazione basata su container, infatti, non ha particolari limiti per quanto riguarda grandezza e complessità. Il passaggio da un’applicazione monolitica ad un paradigma a microservizi è molto più “soft” ed intuitivo, anche in assenza di competenze particolari. Il frazionamento del codice che comporta un contesto serverless risulterebbe sicuramente un’evoluzione più ostica, in quanto vanno considerati fattori come la disponibilità immediata della funzione e potenziali ritardi di avvio.

L’utilizzo dei container permette inoltre, avendo completo controllo dell’infrastruttura ospitante e dei singoli container, di poter gestire come si desidera questioni come la sicurezza, il debugging, il testing, il monitoraggio, che nel caso di Serverless risultano sicuramente più complesse perché ottenibili solamente attraverso strumenti messi a disposizione del provider.
I container sono portabili e vendor-agnostic. Le funzioni Serverless, soprattutto se integrate con altri servizi messi a disposizione dallo stesso provider, non lo sono.

D’altra parte, l’utilizzo dei container rispetto alle funzioni Serverless, comporta alcuni accorgimenti in più:

Il ciclo di vita di un container, non essendo gestito da un’azienda terza, deve essere manutenuto costantemente e monitorato.
In secondo luogo è necessario fare attenzione ai costi di esecuzione: mentre nelle funzioni Serverless la maggiore o minore necessità di risorse è gestita interamente dal provider, nell’utilizzo di container si può più facilemente cadere nella problematica ancestrale di server sovradimensionati e di risorse inutilizzate.

In conclusione: Serverless e container possono lavorare insieme!

Per tantissimi aspetti le due tecnologie hanno punti di forza che sono complementari tra di loro andando a soppere i limiti l’una dell’altra: non si può che trarne grande beneficio!

È possibile ad esempio fare affidamento in una architettura a microservizi basati su container per quanto riguarda operazioni che necessitano di un’esecuzione continua, mentre è possibile affidarsi a funzioni serverless in caso di “small tasks” di back-end come il trasferimento dati o il backup di alcune risorse. Ciò consente di risparmiare denaro e potrebbe aumentare le prestazioni dell’applicazione.

Per venire incontro a queste esigenze, esiste AWS Fargate, che è una sorta di ibrido tra container e serverless che, consentendo di eseguire container senza dover gestire server o cluster, viene in soccorso su alcuni dei problemi che ciascuna di queste tecnologie presenta.

Fargate combina la portabilità dei contenitori con l’elasticità e la facilità d’uso di Serverless.

Per approfondire alcuni degli argomenti trattati, vi suggerisco alcuni dei link utili:

https://www.docker.com/resources/what-container

https://www.docker.com/get-started

https://aws.amazon.com/it/fargate/

https://cloud.google.com/containers/?hl=it

https://www.g2.com/categories/container-management

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *