Le ragioni della rimozione da parte di Red Hat del Docker Container Runtime in funzione di Podman sono solo tecniche?

11

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:

  1. il livello di maturità del progetto Podman (come cita Wallen);
  2. 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?

Da sempre appassionato del mondo open-source e di Linux nel 2009 ho fondato il portale Mia Mamma Usa Linux! per condividere articoli, notizie ed in generale tutto quello che riguarda il mondo del pinguino, con particolare attenzione alle tematiche di interoperabilità, HA e cloud.
E, sì, mia mamma usa Linux dal 2009.

11 risposte a “Le ragioni della rimozione da parte di Red Hat del Docker Container Runtime in funzione di Podman sono solo tecniche?”

  1. Avatar TristanTarrant
    TristanTarrant

    Fandonie 🙂
    I vantaggi di podman su docker sono squisitamente tecnici, soprattutto in ottica di semplicita’ e security.

    Puoi continuare a installare docker su RHEL/Fedora/CentOS utilizzando i repo di Docker: https://docs.docker.com/install/linux/docker-ce/centos/
    Red Hat semplicemente non vuole piu’ sobbarcarsi il packaging e il supporto di un componente che ha una valida alternativa.

  2. Avatar TristanTarrant
    TristanTarrant

    Quando uno non ha argomenti puo’ solo rispondere cosi’.

    Tutta la dietrologia di Wallen non vale i byte in cui e’ codificata.
    La strategia di Red Hat sui container parte da molto lontano e gia’ l’acquisizione di CoreOS ne era un grosso tassello.

    E il vero investimento e’ su Kubernetes, dove Docker e’ solo una palla al piede: se ho gia’ un orchestratore come Kube, perche’ tirarmi dietro anche l’inutile demone di Docker quando posso creare container con molto meno.

  3. Avatar Raoul Scarazzini
    Raoul Scarazzini

    Sì, però principalmente dovresti stare sereno, la mia era una battuta, anche perché se leggi con attenzione l’ho scritto chiaramente come io ritenga che le ragioni di Red Hat siano “realmente credibili e condivisibili”. Fermo restando però che tutta la questione Podman/Buildah/Skopeo aggiunge complessità ad un tema che necessiterebbe invece dell’opposto (cosa che docker garantiva).

    Detto questo però, chiamare “dietrologia” quella di Wallen lo trovo da parte tua miope e (ma questo è anche comprensibile) aziendalista. Le argomentazioni che propone sono reali, condivisibili e, per quanto mi riguarda, solo la punta dell’iceberg di quanto avverrà nel futuro.
    Solo il tempo ci dirà chi aveva più ragione, io penso solo che i segnali siano piuttosto inequivocabili.

  4. Avatar Raoul Scarazzini
    Raoul Scarazzini

    Non penso che chi usa Docker sottostà ad un vendor lock-in. Docker si è diffuso così tanto per via del fatto che le reali alternative ci hanno messo parecchio ad arrivare ed è più che normale che l’azienda Docker (al netto dei pasticci coi nomi tra docker-ce, docker-ee, Moby e compagnia bella) abbia cercato di monetizzare (fallendo, peraltro, per via di tutte le vicende che hai giustamente menzionato).
    Però qui si discute sulla posizione di Red Hat ed in questo senso le argomentazioni di Wallen rimangono solide.
    Nessuno mette in discussione la bontà di Podman e compagnia, quanto piuttosto il totale monopolio che Red Hat ha su Linux ed il fatto che IBM ne vorrà approfittare senza se e senza ma (e te credo, dopo aver speso 34 miliardi).
    Una delle argomentazioni di Wallen che più ho condiviso è stato l’accostamento a systemd: Docker è un colosso accentratore pesante e inutile, quindi Podman/Buildah/Skopeo sono meglio. Systemd è un colosso accentratore leggero e funzionale, quindi non c’è niente di meglio.
    Concorderai che ad un esterno questo appare come un atteggiamento schizofrenico.

  5. Avatar spupuz
    spupuz

    La acquisizione più grossa dell’informatica è stata l’acquisto di EMC da parte di Dell 67 billion $

  6. Avatar Giovanni Virdis

    L’acquisizione di RedHat è stata per IBM una manovra per rientrare dalla finestra dopo essere stata buttata fuori dalla porta.. Molti grandi clienti (per esempio: in ambito bancario) hanno buttato fuori IBM per sostituirlo con infrastrutture (open?) principalmente RedHat. Con l’acquisizione di RedHat, Ibm è, rientrata dalla finestra. Podman non è tutto questo miracolo, non è la panacea e non ha la maturità di docker. Semplicemente: IBM spinge su Podman per questioni interne che di tecnico non hanno assolutamente niente.

  7. Avatar darkcg
    darkcg

    Francamente non condivido, almeno in parte. Per alcuni tipi di workload, ovvero quelli solo runtime, potrebbe essere come dici tu. Per altri, podman / buildah costituiscono una limitazione. Di fatto, con buildah buildi i container esclusivamente nella tua macchina locale, quindi presenta anche casi d’uso estremamente limitati. Con il demone Docker, invece, posso costruire build server di containers sul quale buildo immagini non necessariamente sulla stessa macchina dove eseguo strumenti di continuous integration. Nella mia azienda ho implementato un sistema di continuous integration basato su Jenkins dove le immagini vengono buildate su un build server di immagini differente. Questo grazie al demone Docker, che consente di controllare il demone e le operazioni da eseguire mediante una connessione TCP e delle API REST. I vantaggi sono ovvi, specie se oltre alla continuous integration fai anche continuous delivery: posso avere un server Jenkins moderatamente modesto come specifiche hardware, demandando le build delle applicazioni a degli agenti Jenkins piu potenti e grazie al Docker daemon avere un “agente” demandato alle sole build dei container. Non solo, ma le recenti implementazioni di Docker buildx consentono di implementare delle vere e proprie build farm utilizzando il demone Docker. Non è che avere un demone sia sempre il male. Posso capire che molte situazioni di solo runtime possano richiedere un qualcosa di piu leggero e semplice (per esempio Kubernetes si è comunque implementato CRI-O) ma comunque Docker è molto di piu di un semplice lanciatore di container. E’ un vero e proprio tool di sviluppo DevOps. Ma poi, filosofia a parte, capirai che overhead: Docker ormai è una lingua franca e consente di effettuare determinate operazioni con una semplicità disarmante.

  8. Avatar TristanTarrant
    TristanTarrant

    @darkcg:disqus e @pensavodiavercapito:disqus mi ero dimenticato di questo battibecco. Ma viste le azioni di Docker degli ultimi mesi, ringraziate Red Hat per l’esistenza di Podman. E fanculo Docker, Inc. (l’azienda, non il software)

  9. Avatar Raoul Scarazzini

    @TristanTarrant però questo necro posting è illegale 😀

  10. Avatar darkcg
    darkcg

    Cioè, quali azioni? Provare a introdurre una licenza commerciale ad uso professionale per il solo docker desktop?

Lascia un commento

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