Ciao, e benvenuto nella prima puntata della dodicesima stagione di questo podcast. Dopo un lungo viaggio nella storia del Web, questa stagione cambia registro: è una stagione tecnica e pratica, dedicata a uno strumento che ha trasformato il modo in cui costruiamo e distribuiamo il software. Uno strumento che chi lavora oggi nello sviluppo incontra ovunque, e che porta un nome ormai famosissimo: Docker. Ma prima di dire cos'è, oggi partiamo dal problema che è nato per risolvere, perché senza capire il problema, la soluzione sembra magia incomprensibile.
Il problema ha un nome quasi leggendario tra gli sviluppatori, una frase che è diventata una battuta amara ripetuta in tutto il mondo: sul mio computer funziona. È la frase che uno sviluppatore pronuncia, sconsolato, quando il suo programma gira perfettamente sulla sua macchina, ma poi si rifiuta di funzionare su quella di un collega, o sul server dove dovrebbe andare in produzione. Lo stesso identico codice, che va benissimo in un posto e si rompe in un altro. È una delle esperienze più frustranti e più comuni di tutta la programmazione, e ha fatto perdere ore e ore a intere generazioni di sviluppatori.
Perché succede questa cosa apparentemente assurda? La risposta sta in una parola: l'ambiente. Un programma, per funzionare, non ha bisogno solo del suo codice: ha bisogno di tutto un mondo attorno a sé. Ha bisogno che sul computer sia installata la giusta versione del linguaggio in cui è scritto, le giuste librerie di supporto, con le versioni giuste, certi strumenti di sistema, certe impostazioni di configurazione. Tutto questo contorno è l'ambiente in cui il programma vive. E il problema è che questo ambiente, sul tuo computer, è diverso da quello del tuo collega, e diverso ancora da quello del server.
Facciamo un esempio concreto per rendere l'idea. Immagina di scrivere un programma sul tuo computer, dove hai installato una certa versione del tuo linguaggio, diciamo la versione più recente. Il tuo programma la usa e funziona benissimo. Poi mandi il codice al server, dove però è installata una versione più vecchia dello stesso linguaggio, che non capisce alcune cose che tu hai usato. Il programma si rompe. Non perché il codice sia sbagliato, ma perché l'ambiente attorno è diverso. Moltiplica questo per decine di librerie, strumenti e impostazioni, ciascuno con la sua versione, e capisci come sia facile che due ambienti divergano e che il codice funzioni qui e non là.
Questo problema, che chiamiamo mancanza di riproducibilità, diventa ancora più doloroso quando si lavora in gruppo, e riprende un tema della prima stagione. Immagina un team di dieci sviluppatori: ciascuno ha il proprio computer, configurato a modo suo, con le sue versioni di tutto. Far sì che il progetto funzioni allo stesso modo sulle macchine di tutti e dieci, e poi anche sul server, diventa un incubo. Ognuno perde giorni a sistemare il proprio ambiente, a inseguire differenze sottili, a chiedersi perché a lui non funziona ciò che al collega va. È un enorme spreco di tempo e di energie, che distrae dal lavoro vero, quello di costruire il prodotto.
Prima di Docker, si tentava di risolvere questo problema in modi faticosi e imperfetti. Si scrivevano lunghi documenti che spiegavano, passo per passo, come configurare il proprio ambiente, sperando che tutti li seguissero senza errori. Si usavano strumenti complicati per cercare di rendere gli ambienti uguali. Ma erano rimedi fragili: bastava un piccolo scostamento, una versione leggermente diversa, e il problema tornava. Mancava un modo semplice e affidabile per dire, con certezza: questo programma deve girare sempre esattamente in questo ambiente, ovunque lo porti, senza eccezioni. Quella certezza era il sogno, e nessuno era ancora riuscito a realizzarla davvero in modo comodo.
Ed è esattamente questo il buco che Docker è venuto a riempire, e ti anticipo l'idea di fondo, che approfondiremo nella prossima puntata. E se, invece di sperare che l'ambiente sul computer di destinazione sia quello giusto, impacchettassimo il programma insieme a tutto il suo ambiente, in un'unica scatola sigillata? Se il programma portasse sempre con sé, ovunque vada, il proprio mondo su misura, le versioni giuste di tutto, le librerie giuste, la configurazione giusta, indipendentemente dal computer su cui viene eseguito? Allora funzionerebbe sempre allo stesso modo, perché non dipenderebbe più dall'ambiente esterno: se lo porterebbe dietro. Questa scatola è il container, il cuore di tutta la stagione.
Per oggi ci fermiamo qui. Il problema che Docker risolve è racchiuso in una frase famosa, sul mio computer funziona: lo stesso codice gira in un posto e si rompe in un altro, non per colpa del codice, ma perché l'ambiente attorno, le versioni del linguaggio, delle librerie, degli strumenti, è diverso. Questo problema di mancata riproducibilità è un incubo, soprattutto in gruppo, e i vecchi rimedi erano fragili. L'idea rivoluzionaria è impacchettare il programma insieme a tutto il suo ambiente in un'unica scatola, che porta il proprio mondo ovunque. Nella prossima puntata apriamo questa scatola: cos'è un container. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.