Uso Docker tutti i giorni.
In sviluppo, in produzione, su progetti miei e su quelli del lavoro. È entrato nel mio toolkit tanti anni fa senza fare troppo rumore — e non ne sono mai uscito. Ha i suoi limiti, e li conosco. Ma funziona. E funziona in modo abbastanza prevedibile da non farmi perdere tempo.
Qualche settimana fa Communications of the ACM ha pubblicato un articolo che ripercorre il primo decennio di Docker. Ogni occasione per fermarsi a ragionare su come certe tecnologie diventano standard è una buona occasione.
E quello che mi interessa non è tanto l'articolo. È la discussione che ha generato.
Perché per celebrare il primo decennio di Docker, una buona fetta della comunità tecnica ha colto l'occasione per ricordare quanto sia tecnicamente sbagliato.
Hanno ragione
Non è una provocazione. Sul piano tecnico molte critiche reggono.
L'ecosistema Unix era stato pensato per condividere le librerie tra applicazioni. Docker fa esattamente il contrario: impacchetta tutto insieme, duplicando runtime e dipendenze dentro ogni container. Da un punto di vista teorico è quasi un passo indietro.
E c'è chi lo fa notare con precisione: se il mondo funzionasse diversamente, sistemi come Nix o Bazel avrebbero risolto il problema in modo molto più corretto. Build riproducibili, dependency graph espliciti, niente duplicazioni. Formalmente giusti.
Non è aria fritta. Nix esiste, funziona, e chi lo usa giura che non tornerebbe indietro.
La teoria però non paga le bollette
Il problema che Docker ha risolto non era teorico.
Era: far girare il software su un altro computer. Chiunque abbia lavorato su backend negli anni 2000 ricorda cos'era prima. Versioni di librerie che non coincidono, deploy che si trasformano in sessioni di debugging senza fine. Works on my machine era la risposta standard… e nessuno rideva.
È sbagliato dal punto di vista della purezza del design? Sì. Ha eliminato una classe intera di problemi pratici? Assolutamente sì.
E qui sta il punto che i puristi faticano ad accettare: Docker non ha convinto nessuno con
argomenti tecnici. Ha convinto perché il giorno dopo averlo scoperto riuscivi già a usarlo.
Dockerfile, Docker Hub, docker run, docker compose up -d.
Un modo per costruire, un posto dove pubblicare, un comando per eseguire. Non era la
tecnologia… i container esistevano già da anni, tra chroot, LXC e cgroups. Era
l'esperienza.
Il purismo ha un costo nascosto
C'è una cosa che non viene mai detta esplicitamente in queste discussioni.
Nix è potente. Bazel è potente. Ma hanno una curva di adozione che scoraggia chiunque non abbia già una motivazione forte per salirci. Non è una critica alla qualità tecnica, è un'osservazione su come funziona l'adozione nella realtà. Gli strumenti eleganti richiedono che tu capisca il loro modello mentale prima di essere produttivo. Docker ti chiedeva solo di scrivere un file e lanciare un comando.
I puristi ragionano come se il problema fosse solo trovare la soluzione corretta. Ma nel software il problema è anche, e spesso soprattutto, far adottare la soluzione.
Se non la usa nessuno, il problema resta lì.
Ma la storia non premia chi ha ragione
PHP è pieno di incoerenze storiche che farebbero inorridire qualsiasi language designer. JavaScript è pieno di decisioni discutibili prese in fretta. Git ha un modello interno che ancora oggi fa discutere.
Sono tutti standard de facto. Non perché siano perfetti, ma perché hanno abbassato la frizione abbastanza da essere adottati, usati, e poi dati per scontati. Docker è in quella lista. E ci è arrivato nonostante una comunità tecnica che ne sottolineava i limiti, non grazie al suo endorsement.
Oggi l'ecosistema si è evoluto: Kubernetes, OCI, runtime alternativi. Ma l'idea di fondo è rimasta. Il software deve essere portabile.
E quella battaglia l'ha vinta un hack, non una soluzione elegante.
Quindi cosa rimane?
Continuo a usare Docker. E continuo a trovare legittimo chi lo critica sul piano tecnico.
Ma quando leggo certi commenti mi rimane sempre una domanda: quanta della produzione mondiale gira su Nix oggi?
La risposta dice tutto.