Ciao, e benvenuto nella terza puntata della dodicesima stagione. Nella scorsa puntata abbiamo conosciuto il container, la scatola isolata che porta con sé tutto l'ambiente del programma. Ma a questo punto una persona attenta si fa una domanda legittima: ma questa idea non esisteva già? Non c'erano forse, da tempo, le macchine virtuali che facevano qualcosa di simile? La domanda è giusta, e la risposta è illuminante. Oggi confrontiamo i container con le macchine virtuali, e capiamo perché i container sono così leggeri e veloci, e perché questa leggerezza ha cambiato tutto.
Partiamo dalle macchine virtuali, che esistevano da molto prima di Docker e che risolvevano un problema simile. Una macchina virtuale è, come dice il nome, un intero computer finto, simulato dentro il tuo computer vero. Con essa puoi far girare un secondo sistema operativo completo dentro il tuo, come se avessi un altro computer intero racchiuso in una finestra. Anche la macchina virtuale offre isolamento e ambienti separati, ed è stata per anni il modo principale di isolare i programmi. Quindi, in effetti, l'idea di ambienti isolati non era nuova. La novità dei container sta nel come lo fanno, e la differenza è enorme.
Ecco il punto cruciale, e cerco di renderlo intuitivo. Una macchina virtuale simula un computer intero, dalle fondamenta in su: deve avere un suo sistema operativo completo, con tutto il suo peso, che gira insieme al tuo. È come costruire una casa completa e indipendente dentro il tuo giardino, con le sue fondamenta, i suoi muri, i suoi impianti, ogni volta. Un container, invece, non simula un computer intero: condivide con il tuo computer le fondamenta comuni, il cuore del sistema operativo, e isola solo ciò che serve al programma. È come costruire non una casa nuova, ma solo una stanza separata dentro una casa già esistente, sfruttando le fondamenta e i muri portanti già presenti.
Questa differenza, apparentemente tecnica, ha conseguenze pratiche enormi, e sono il cuore della puntata. Siccome la macchina virtuale porta con sé un intero sistema operativo, è pesante: occupa molto spazio, consuma molta memoria, e ci mette parecchio tempo ad avviarsi, spesso minuti, come un computer vero che si accende. Il container, non dovendo trascinarsi dietro un sistema operativo completo ma solo il necessario, è leggerissimo al confronto: occupa poco spazio, consuma poca memoria, e si avvia in una frazione di secondo, quasi istantaneamente. La differenza di leggerezza e velocità tra i due è di ordini di grandezza. È come la differenza tra spostare una casa intera e spostare una scatola.
Fermiamoci a capire perché questa leggerezza cambia davvero tutto, perché non è un dettaglio da poco. Se avviare un ambiente isolato costa minuti e molte risorse, come con le macchine virtuali, allora ne puoi avere pochi, e li tratti come cose preziose e durature. Ma se avviare un ambiente isolato costa una frazione di secondo e pochissime risorse, come con i container, allora puoi averne tantissimi, avviarli e spegnerli in continuazione, trattarli come cose usa e getta. Questo cambia radicalmente cosa puoi fare: puoi far crescere un'applicazione avviando cento container in pochi secondi quando serve, e spegnerli quando il picco passa. La leggerezza abilita modi di lavorare che con le macchine virtuali erano impensabili.
Ricordi la stagione sul backend, quando parlavamo di far crescere le applicazioni affiancando tanti server? I container si sposano perfettamente con quell'esigenza. Poter avviare in un istante decine o centinaia di copie identiche e leggere del proprio programma è esattamente ciò che serve per reggere la scala in modo flessibile. I container sono diventati, per questo, il mattoncino con cui si costruiscono le grandi applicazioni moderne che devono crescere e ridursi di continuo. La loro leggerezza non è solo una comodità: è ciò che li rende adatti al mondo dei sistemi che devono scalare all'istante.
Devo però essere onesto ed equilibrato, perché i container non sono sempre e comunque meglio delle macchine virtuali, e la scelta dipende dal contesto. Le macchine virtuali, essendo computer interi separati, offrono un isolamento più forte e completo: siccome ogni macchina virtuale ha il suo sistema operativo, la separazione dal resto è più netta e robusta. I container, condividendo le fondamenta con il computer ospite, hanno un isolamento un po' meno rigido, il che in certi contesti molto sensibili può contare. Non è che uno sia buono e l'altro cattivo: sono strumenti diversi, con compromessi diversi tra leggerezza e isolamento. Spesso, addirittura, si usano insieme, con i container che girano dentro le macchine virtuali.
Per oggi ci fermiamo qui. Le macchine virtuali risolvevano già il problema dell'isolamento, ma simulando un computer intero, con un sistema operativo completo: pesanti, lente ad avviarsi, avide di risorse. I container fanno una cosa più furba: condividono le fondamenta con il computer ospite e isolano solo il necessario, risultando leggerissimi e velocissimi, avviabili in una frazione di secondo. Questa leggerezza cambia tutto, perché permette di trattare gli ambienti come usa e getta e di scalare all'istante. Il prezzo è un isolamento un po' meno rigido: strumenti diversi, compromessi diversi. Nella prossima puntata distinguiamo due concetti che spesso si confondono: l'immagine e il container. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.