Normare i container Linux: un ritornello già sentito un anno fa

C’è veramente il rischio di una pericolosa frammentazione dell’ecosistema dell’open computing e di riportare indietro l’It ai termpi di Unix? Per ovviare al problema servono standard che sostengano l’interoperabilità a livello di orchestrazione. Ne parla chi è alla guida delle organizzazioni che si muovono in questa direzione.

All’inizio del 2015, l’ecosistema dei container Linux si è trovato ad affrontare il reale pericolo di una frammentazione, con una serie di formati e standard in competizione fra loro che minacciavano di negare la promessa portabilità rappresentata dalle applicazioni containerizzate e dalle infrastrutture che le supportano.

Questa tendenza a operare per compartimenti stagni potrebbe riportare il settore dell’It ai tempi di Unix, con costose soluzioni fatte su misura e un’interoperabilità limitata, quando non assente, tra le diverse soluzioni. La preoccupazione di avere soluzioni frammentate e non interoperabili ha portato diverse aziende a cambiare atteggiamento verso i container, passando dalla decisione di adottarle a un approccio di attesa.

Per poter essere adottati su larga scala, i container Linux avevano la necessità di essere standardizzati, preferibilmente adottando principi open source, con il supporto degli attori principali del settore It. Questo però non è stato facile.

Ad aggiungere complessità al problema c’è il fatto che i container Linux non cadono sotto un’unica categoria di standardizzazione. Piuttosto, ha senso guardare alla standardizzazione dei container da tre punti di vista differenti, ciascuno corrispondente a un livello di stack (o Ldk, sigla che sta per Linux, Docker e Kubernetes) del container.

L(inux). Il nome della tecnologia è già di per sé un’indicazione: il sistema operativo Linux forma la base della tecnologia dei container. Mentre i container richiedono solo la base minima di un sistema operativo, le loro esigenze di isolamento, sicurezza, allocazione delle risorse e gestione dei processi sono garantite da una piattaforma Linux.

D(ocker). Il livello di container di cui si parla più spesso è il formato delle immagini, e Docker è oggi il più comune; ne esistono altri, tuttavia, da cui la necessità di sviluppare standard di interoperabilità per formati esistenti e per quelli che saranno creati in futuro.

Questi standard devono consentire l’uso di diversi strumenti di runtime e gestori di processo per istanziare e gestire i container per mezzo di API standard.

K(ubernetes). Al livello più alto c’è lo strato di orchestrazione, dove diversi servizi di applicazione in container sono mischiati in applicazioni composite complesse.

Analogamente a Docker, Kubernetes è il motore di orchestrazione più comunemente utilizzato, ma ne sono emersi altri. Inoltre, l’orchestrazione va molto al di là dei container e riguarda altre aree tecnologiche quali Apache Mesos e Docker Swarm. Dunque, degli standard che sostengano l’interoperabilità a livello di orchestrazione sono fondamentali.

Piuttosto che lasciare che la frammentazione rallenti la corsa all’adozione dei container Linux, gran parte del comparto It si è riunito attorno a due organizzazioni di settore che mirano a definire standard per i rispettivi aspetti della questione.

La Open Container Initiative (Oci), mira a codificare e standardizzare i formati e i runtime. La Cloud Native Computing Foundation (Cnfc), formatasi attorno all’esigenza di supportare le applicazioni più attuali, fornire come composizione di (micro) servizi in container.

La seconda prevede di collaborare con la prima per la definizione dei runtime e delle immagini dei container e include Kubernetes come motore di orchestrazione dei container.

È importante notare che gli standard nel mondo It sono percepiti come lenti nel seguire l’evoluzione del mercato, eccessivamente complessi e non basati su esperienze di implementazione sul campo, e controllati da una ristretta élite.

La situazione oggi sta cambiando grazie alla combinazione delle migliori pratiche relative agli standard aperti e allo sviluppo dell’open source.

Grazie alla natura open source dei container e dei progetti che supportano questa tecnologia, aziende che normalmente sono in concorrenza, sviluppatori singoli e clienti/utenti possono collaborare direttamente a livello di tecnologia.

Il codice può infatti essere redatto velocemente, rivisto in maniera trasparente e basarsi su standard stabiliti in tempi molto più rapidi di quelli richiesti per modificare gli standard tradizionali.

Alla guida di entrambe queste iniziative, oltre che del concetto stesso di standard per l’open source, c’è Red Hat, che svolge un ruolo attivo nell’aiutare a porre le fondamenta sia per Oci sia per Cnfc.

Entrambe queste organizzazioni sono nate nell’arco di pochi mesi nel 2015 e si sono poste l’obiettivo di portare ordine nel caos percepito attorno al Far West del mondo dei container Linux.

Qual è a oggi lo stato di avanzamento dei lavori in entrambe le organizzazioni? Ci si sta muovendo con la rapidità necessaria?

Nel corso delle prossime settimane, Red Hat analizzerà le organizzazioni, le tecnologie e gli standard emergenti per ciascun componente dell’LDK. La standardizzazione dei container sta arrivando, ma sta arrivando abbastanza velocemente?

Chris Wright, Vice President and Chief Technologis di Red Hat