Ciao, e benvenuto nella quinta puntata della decima stagione. Nelle scorse puntate abbiamo raccolto i pezzi del backend: i linguaggi, il database, i framework. Oggi li mettiamo insieme in un disegno d'insieme, l'architettura classica con cui è stata costruita la stragrande maggioranza delle applicazioni web della storia. E conosciamo il protagonista di quest'epoca, una parola che oggi viene spesso pronunciata con un po' di sospetto, ma che merita di essere capita e rivalutata: il monolite.
Partiamo dall'architettura a tre livelli, perché è lo schema mentale che ha organizzato il Web per decenni. Immagina di dividere un'applicazione in tre grandi strati sovrapposti. In alto, lo strato della presentazione: ciò che l'utente vede e con cui interagisce, che oggi chiameremmo frontend. In mezzo, lo strato della logica: le regole, i ragionamenti, ciò che l'applicazione sa fare. In basso, lo strato dei dati: il database, la memoria permanente di cui abbiamo parlato. Tre livelli, ciascuno con un ruolo chiaro, che collaborano dall'alto verso il basso e viceversa.
Questa divisione in tre strati non è un dettaglio tecnico, ma un modo profondo e sano di pensare, che riprende un tema ricorrente del podcast. È di nuovo l'idea di separare le responsabilità, di dare a ogni parte un compito solo e ben definito. La presentazione non si preoccupa di come sono conservati i dati; la logica non si preoccupa dei dettagli di come le cose vengono mostrate; i dati non sanno nulla di ciò che ci viene fatto sopra. Questa separazione rende il sistema più ordinato, più comprensibile e più facile da modificare, perché puoi cambiare uno strato senza sconvolgere gli altri. È buona architettura, ieri come oggi.
Ora, per lungo tempo, il modo normale di realizzare questi tre livelli è stato costruirli come un'unica grande applicazione, un solo blocco di codice che conteneva tutto: la presentazione, la logica, il dialogo con il database, ogni funzionalità, tutto insieme, in un unico programma che girava come un tutt'uno. Questo è il monolite: un'applicazione singola, unita, in cui tutte le parti vivono nello stesso posto e vengono costruite e messe in funzione come una cosa sola. Per decenni, questo è stato semplicemente il modo in cui si facevano le applicazioni, senza bisogno di dargli un nome.
Oggi la parola monolite ha spesso un suono negativo, come se fosse qualcosa di goffo e antiquato, e voglio subito correggere questa impressione, perché è ingiusta. Il monolite ha delle virtù enormi, soprattutto la semplicità. Tutto è in un posto solo: è facile da capire nel suo insieme, facile da mettere in funzione, facile da sviluppare quando l'applicazione non è gigantesca. Non devi coordinare tanti pezzi separati, non devi gestire dialoghi complicati tra parti distanti. Per la maggior parte delle applicazioni, per gran parte della loro vita, il monolite è stato, ed è ancora, la scelta più sensata e ragionevole. Semplice non significa arretrato.
Da dove viene, allora, la cattiva fama? Viene dai problemi che il monolite mostra quando l'applicazione diventa enorme, e questi problemi sono il seme di tutto ciò che racconteremo nelle prossime puntate. Quando un monolite cresce a dismisura, con centinaia di persone che ci lavorano e milioni di utenti, la sua unità, che era una forza, diventa un peso. Diventa un blocco così grande e intrecciato che è difficile da capire per intero, rischioso da modificare perché toccando una parte puoi rompere un'altra parte lontana, e faticoso da far crescere, perché per potenziarne un pezzetto devi ingrandire l'intero blocco.
Fermiamoci su quest'ultimo punto, la scala, perché è il vero tallone d'Achille e apre la porta al resto della stagione. Immagina che in tutta la tua applicazione ci sia solo una piccola funzione usatissima, magari la ricerca, che ha bisogno di molta più potenza delle altre. In un monolite non puoi potenziare solo quella: siccome è tutto un blocco unico, per dare più potenza alla ricerca devi replicare e ingrandire l'intera applicazione, sprecando risorse per tutto il resto che non ne aveva bisogno. Questa incapacità di far crescere le singole parti in modo indipendente diventava, per i colossi del Web, un limite sempre più insopportabile.
E qui arriviamo alla tensione che guiderà il cuore di questa stagione, la stessa che abbiamo incontrato per il frontend: la tensione tra la semplicità e la scala. Il monolite è semplice e sano, perfetto per la maggior parte dei casi, ma fatica a reggere le dimensioni estreme. E il Web, con alcuni suoi protagonisti diventati giganteschi, cominciò a spingere contro questi limiti, cercando modi nuovi di costruire per servire numeri mai visti prima. Le soluzioni che nasceranno da questa spinta, come vedremo, risolveranno il problema della scala, ma al prezzo di rinunciare proprio a quella preziosa semplicità. Il pendolo, ancora una volta, sta per oscillare.
Per oggi ci fermiamo qui. L'architettura classica del backend divide l'applicazione in tre livelli, presentazione, logica e dati, incarnando la sana separazione delle responsabilità. Per decenni questi livelli sono stati realizzati come un monolite, un'unica applicazione che contiene tutto: una scelta semplice e ragionevole, ingiustamente disprezzata oggi. Ma il monolite fatica quando l'applicazione diventa enorme, soprattutto perché non permette di far crescere le singole parti in modo indipendente. Da questa tensione tra semplicità e scala nascerà tutto il resto. Nella prossima puntata affrontiamo di petto la sfida della scala. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.