Le ragioni della rimozione da parte di Red Hat del Docker Container Runtime in funzione di Podman sono solo tecniche?
Il tema di questo articolo non è nuovissimo, ma è interessante raccogliere pareri autorevoli di persone che legittimamente si pongono domande in merito all’acquisizione di Red Hat da parte di IBM.
Ci siamo chiesti da sempre perché mai IBM avrebbe dovuto comprare Red Hat per 34 miliardi di dollari per lasciare l’azienda esattamente com’era, interrogandoci sulla più grossa acquisizione nella storia dell’informatica e sulle cifre che l’hanno contraddistinta. Leggere oggi delle perplessità di Jack Wallen di TechRepublic in merito alla rimozione del supporto alla Docker Container Runtime da parte di Red Hat ci fa capire come, quantomeno, non siamo gli unici.
Il fatto che Wallen scriva principalmente articoli tecnici, il vederlo esporsi così chiaramente sulla questione è sintomo di come il tema sia molto sentito, forse perché lo stesso autore ha da sempre utilizzato con soddisfazione la Docker container runtime come, verrebbe da aggiungere, un’enorme quantità di utenti.
Ma cos’ha detto di così essenziale? Riducendo all’osso le frasi clou sono le seguenti:
Red Hat is now owned by IBM. IBM was desperate to gain serious traction within the cloud. To do that, IBM needed Red Hat, so they purchased the company. Next, IBM had to score a bit of vendor lock-in. Using a tool like docker wouldn’t give them that lock-in. However, if Red Hat developed and depended on their own container runtime, vendor lock-in was attainable.
Red Hat è oggi proprietà di IBM. IBM era alla disperata ricerca di un’acceleratore nel mercato cloud. Per fare questo IBM aveva bisogno di Red Hat e così ‘hanno acquistata. Successivamente, IBM aveva necessità di registrare un minimo di vendor lock-in [ad esempio per non perder i clienti pregressi]. Utilizzare docker non avrebbe consentito di attuare quel tipo di lock-in. Ciononostante, se Red Hat avesse sviluppato e reso dipendente la propria container runtime, allora il vendor lock-in risultava ancora raggiungibile.
Semplice, chiaro, lineare. Ed il ragionamento in sé giustifica il motivo per cui la tecnologia Podman (cioè il sostituto di Docker) sia stata inclusa ed indicata come piattaforma adibita alla gestione dei container in Red Hat Enterprise 8, nonostante il livello di maturità non fosse ancora così elevato.
Il che dimostra, o almeno spinge a pensare, il fatto che l’acquisizione di Red Hat da parte di IBM fosse stata decisa ben prima dell’ottobre 2018.
Certo, le giustificazioni (parola infelice, ma che rende l’idea) da parte di Red Hat sui benefici dell’utilizzo di Podman sono realmente credibili e condivisibili, ma ci sono almeno due grossi scogli:
- il livello di maturità del progetto Podman (come cita Wallen);
- il livello di complessità aggiunto a tutti il palinsesto container dall’utilizzo di tre strumenti diversi (podman, buildah e skopeo) per fare ciò che prima si faceva con uno solo (docker);
Per il primo punto problemi non ce ne sono, quando Red Hat Enterprise 8 sarà sufficientemente diffusa (ai livelli della versione 7) saremo di fronte ad una stabilità generale decisamente elevata, mentre colmare il livello di complessità introdotto sarà molto semplice. Come? Utilizzando i software Red Hat (come OpenShift, la cui ultima release annunciata si pone come riferimento a chiunque voglia usare Kuberenets in ambito enterprise.
Come dare torto quindi alla persona (non ben identificata) di Red Hat che, interpellata da thenewstack.io, ha risposto così alle perplessità di Wallen:
We saw our customer base wanting the container runtime lifecycle baked-in to the OS or in delivered tandem with OpenShift.
Vediamo la nostra base clienti gestire l’intero ciclo di vita del container runtime direttamente dal sistema operativo oppure distribuito mediante OpenShift
Potrebbe dire altrimenti qualcuno che produce tanto il sistema operativo, quanto lo stesso OpenShift?
Insomma, passi i prodotti che produce, ma perché l’open-organization non ha lasciato agli utenti la possibilità di continuare ad installare Docker?
Se vuoi sostenerci, puoi farlo acquistando qualsiasi cosa dai diversi link di affiliazione che abbiamo nel nostro sito o partendo da qui oppure alcune di queste distribuzioni GNU/Linux che sono disponibili sul nostro negozio online, quelle mancanti possono essere comunque richieste, e su cui trovi anche PC, NAS e il ns ServerOne. Se ti senti generoso, puoi anche donarmi solo 1€ o più se vuoi con PayPal e aiutarmi a continuare a pubblicare più contenuti come questo. Grazie!
Hai dubbi o problemi? Ti aiutiamo noi!
Se vuoi rimanere sempre aggiornato, iscriviti al nostro canale Telegram.Se vuoi ricevere supporto per qualsiasi dubbio o problema, iscriviti alla nostra community Facebook o gruppo Telegram.
Cosa ne pensi? Fateci sapere i vostri pensieri nei commenti qui sotto.
Ti piace quello che leggi? Per favore condividilo con gli altri.
![[GUIDA] Ecco come installare Go (Golang) su Ubuntu Linux](https://www.lffl.org/wp-content/uploads/2021/02/go-ubuntu-download.png "[GUIDA] Ecco come installare Go (Golang) su Ubuntu Linux 3")
