Ciao, e benvenuto nell'ottava puntata della decima stagione. Nella quinta puntata abbiamo conosciuto il monolite, l'applicazione unica e unita, e il suo limite di fronte alla scala estrema. Oggi raccontiamo la risposta architetturale più discussa e ambiziosa a quel limite, quella che ha diviso il mondo del backend in due tifoserie: i microservizi. La grande idea di spezzare l'unico blocco in tanti piccoli servizi indipendenti. È una storia di promesse entusiasmanti e di costi nascosti, che merita di essere raccontata con onestà da entrambi i lati.
Ripartiamo dal problema del monolite, per capire la soluzione. Il monolite era un unico blocco: per far crescere una sua parte dovevi ingrandire tutto, per modificarne un pezzo rischiavi di romperne un altro, e più diventava grande, più diventava lento e rischioso lavorarci, con centinaia di persone che si pestavano i piedi sullo stesso codice. L'idea dei microservizi fu di rispondere a tutto questo con una mossa radicale: e se, invece di un solo grande programma, spezzassimo l'applicazione in tanti piccoli programmi separati, ciascuno responsabile di una sola cosa, ciascuno indipendente dagli altri?
Immagina un grande negozio online. Nel monolite è un unico programma che fa tutto: catalogo, carrello, pagamenti, spedizioni, account. Nei microservizi avresti tanti piccoli servizi separati: uno solo per il catalogo, uno solo per i pagamenti, uno solo per le spedizioni. Ognuno è un programma a sé, che gira per conto suo e collabora con gli altri parlandosi attraverso la rete. Come un'azienda divisa in reparti specializzati, invece di una persona che fa tutto.
Le promesse di questo approccio erano davvero allettanti, e spiegano perché tanti ne furono entusiasti. Primo: potevi far crescere ogni pezzo in modo indipendente. Se solo i pagamenti erano sotto stress, potenziavi solo quel servizio, senza toccare gli altri, risolvendo il grande limite del monolite. Secondo: squadre diverse potevano lavorare su servizi diversi in totale autonomia, senza pestarsi i piedi, ciascuna padrona del suo pezzo. Terzo: se un servizio si guastava, magari gli altri potevano continuare a funzionare, invece di trascinare giù tutto. E ancora: ogni servizio poteva usare la tecnologia più adatta al suo compito. Sulla carta, sembrava la soluzione a tutti i problemi del monolite.
Ma, e qui arriva l'onestà che dobbiamo a questa storia, i microservizi portarono con sé costi enormi e spesso sottovalutati, perché spostarono la complessità invece di eliminarla. Ecco il punto cruciale: nel monolite, le varie parti si parlavano dentro lo stesso programma, in modo immediato e affidabile. Nei microservizi, le parti sono programmi separati che si parlano attraverso la rete, e la rete è lenta, inaffidabile, e a volte cade. Improvvisamente, cose che prima erano semplici e sicure diventavano complicate e rischiose. Avevi trasformato un problema di codice ordinato in un problema di comunicazione tra tanti attori distanti, che è molto più difficile.
Vale la pena elencare questi costi nascosti, perché sono la lezione della puntata. Con tanti servizi separati che si parlano in rete, devi gestire cosa succede quando un servizio non risponde, o risponde in ritardo. Devi tenere coerenti dati sparsi tra tanti servizi diversi, ritrovando quel problema di coerenza di cui abbiamo parlato, ma moltiplicato. Devi capire cosa sta succedendo quando un'operazione attraversa dieci servizi diversi, il che rende difficilissimo seguire i problemi. E devi far funzionare, aggiornare e sorvegliare non più un programma, ma decine o centinaia. La complessità che avevi tolto dal singolo blocco riappariva, moltiplicata, negli spazi tra i servizi.
E qui c'è la lezione più importante, che riprende in pieno lo spirito di questo podcast e che è diventata un monito celebre nel settore: i microservizi non sono per tutti, e adottarli senza averne davvero bisogno è un errore comune e costoso. Molte aziende, affascinate dal modo di lavorare dei giganti del Web, spezzarono i loro monoliti in microservizi quando erano ancora piccole, e si ritrovarono con tutta la complessità dei sistemi distribuiti senza averne i benefici, perché non avevano affatto i problemi di scala che li giustificavano. Si erano dati la pena di un colosso senza esserlo. Riprendo la prima stagione: non imitare le mode dei giganti; scegli in base ai tuoi problemi reali.
Da questa dolorosa esperienza collettiva è emersa una saggezza più matura, che è il lieto fine di questa storia. Oggi molti consigliano di cominciare con un buon monolite ben fatto, semplice e ordinato, e di passare ai microservizi solo se e quando la scala lo richiede davvero, spezzando il monolite con cura, un pezzo alla volta, dove serve. Non è più una guerra di religione tra monolite buono e microservizi cattivi, o viceversa. È una scelta ponderata, legata alla dimensione reale del problema. E c'è persino un ritorno di stima per il monolite ben costruito, che per la stragrande maggioranza dei casi resta la scelta più saggia. Il pendolo, come sempre, ha trovato un equilibrio.
Per oggi ci fermiamo qui. I microservizi rispondono ai limiti del monolite spezzando l'applicazione in tanti piccoli servizi indipendenti, ciascuno responsabile di una cosa sola. Promettono crescita indipendente, autonomia delle squadre e resilienza, ma al prezzo enorme di trasformare la comunicazione interna in comunicazione di rete, lenta e inaffidabile, moltiplicando la complessità. La lezione è non adottarli senza averne bisogno: meglio un buon monolite, e i microservizi solo quando la scala lo esige davvero. Nella prossima puntata l'ultima grande trasformazione: la nuvola e il server che scompare. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.