Normare i container Linux: non ne avevamo già parlato un anno fa?

March 21 2016
Scheda utente
Altri testi utente
RSS utente

di Chris Wright, Vice President and Chief Technologist, Red Hat

Milano - 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, 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 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 dei container Linux:
La Open Container Initiative (OCI), mira a codificare e standardizzare i formati e i runtime
La Cloud Native Computing Foundation (CNCF) formatasi attorno all’esigenza di supportare le applicazioni più attuali, fornire come composizione di (micro) servizi in container. CNFC prevede di collaborare con OCI 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; infatti il codice può 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. L’azienda è all’avanguardia del mondo open source per quanto riguarda le architetture tecnologiche correnti e si è fatta le ossa nella costruzione di una piattaforma Linux basata su standard per l’impresa con Red Hat Enterprise Linux, che rappresenta tutt’ora il modello e il leader di mercato per Linux nel data center. Non è quindi una sorpresa che Red Hat abbia un ruolo attivo nell’aiutare a porre le fondamenta sia per OCI sia per CNCF.

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? E qual è la posizione di Red Hat relativamente a Linux, la componente meno discussa – ma probabilmente più importante – dei container?
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? Rimanete sintonizzati…

Licenza di distribuzione:
© Pensi che questo testo violi qualche norma sul copyright, contenga abusi di qualche tipo? Leggi come procedere