Nell’ecosistema di Docker se ne parla, fra conferme e smentite. Ma perché un “fork” sarebbe possibile e forse conveniente?
L’ecosistema di Docker, la più diffusa piattaforma open source per la containerizzazione del software, è in subbuglio. Secondo The New Stack l’ipotesi di un “fork” circola insistentemente e potrebbe concretizzarsi anche a breve. Alex Williams e Joab Jackson ne parlano qui. Un “fork”, ricordiamo, è lo sviluppo di un progetto software che parte dal codice sorgente di un altro già esistente e – appunto – se ne allontana per biforcazione. Si tratta di un evento tutt’altro che insolito, che tuttavia deve seguire una certa etichetta per non provocare danni agli utenti nella logica dell’open source. Un “fork” va fatto quando è davvero necessario e quando si rivela l’unica opzione possibile, in ogni caso comunicando in modo trasparente le proprie intenzioni.
Ma per quale ragione un’ipotesi di questo tipo è all’ordine del giorno in casa Docker? In fondo stiamo parlando di una piattaforma di grande successo, di gran lunga la più amata dagli sviluppatori. In realtà la tecnologia della containerizzazione non è così nuova (il progetto Linux Containers, per esempio, è attivo da oltre un decennio). Ma Docker l’ha resa particolarmente veloce ed efficiente. Eppure qualcosa non va.
Già nel dicembre di due anni fa CoreOS, startup capitalizzata da Google Ventures e Sequoia, lanciava il container runtime rkt proprio in polemica con Docker. L’accusa era quella di avere tradito la missione originaria e di avere creato un monolite multifunzionale, anziché un singolo elemento componibile. “Docker non è più un container. Ormai è una piattaforma”: con queste parole Alex Povi, CEO di CoreOS, annunciava la secessione da Docker nel post CoreOS is building a container runtime, rkt.
Docker contro tutti: le ragioni dei contendenti
Ma veniamo alle discussioni di oggi. Secondo The New Stack al dibattito starebbero contribuendo Red Hat, Google e Huawei. Oltre alla stessa CoreOS, ovviamente. I diretti interessati negano, ma alla fine lasciano intendere che la questione esiste. Si parla di problemi di stabilità del codice, forse anche a causa di una politica di rilasci troppo aggressiva (gli intervalli di tempo fra una versione del prodotto e quella successiva sono molto brevi). Soprattutto, si critica l’approccio omnicomprensivo di Docker, che non si limita a fornire il container come tre anni fa, ma offre oggi un’ampia gamma di strumenti e servizi integrati con il cuore della piattaforma. Il risultato è che Docker tende a sovrapporsi alle funzionalità già offerte da altri vendor, i quali vorrebbero invece utilizzare solo Docker Engine.
È il caso di Google, che vede Docker Swarm (ovvero le funzionalità di orchestrazione incluse nella versione di Docker 1.12) come una minaccia per il proprio Kubernetes. Del resto neppure AWS vede Swarm di buon occhio, perché teoricamente permetterebbe di portare le applicazioni fuori dal cloud. E anche Apcera, per bocca del suo product manager tecnico Phillip Tribble, ha espresso molte perplessità sul nuovo corso di Docker. L’intervento di Tribble di ieri (The Sad State of Docker) è abbastanza esplicito in proposito.
Se però consideriamo la cosa dal punto di vista della stessa Docker, siamo costretti a riconoscere che la sua strategia evolutiva ha un senso, almeno sul piano strettamente commerciale. Banalizzando: i soldi non si fanno vendendo la mera tecnologia per la containerizzazione, ma integrando tutti i componenti che – nel loro insieme – permettono di configurare sistemi distribuiti su larga scala. Il container è dunque un tassello – certo fondamentale, ma non sufficiente – di un mosaico più vasto. Docker sta cercando di scalare questa montagna partendo dal punto di ingresso più basso, sul quale detiene un vantaggio competitivo enorme. E, nella sua risalita, si scontra con i player posizionati in alto. Come Google, appunto.
Ed ecco la logica del “fork”. Il progetto di Docker può proseguire in una prospettiva open source, con Google & C all’interno dell’ecosistema, a patto che recuperi lo spirito originario: realizzare la migliore tecnologia di containerizzazione, da mettere a disposizione di tutti come building block comune. Tutto il resto è concorrenza.
