Per anni, "microservices" e stata la parola magica dell'architettura software. Vuoi scalare? Microservices. Vuoi deployare piu velocemente? Microservices. Vuoi essere come Netflix? Microservices.
Segment — una delle aziende di data infrastructure piu rispettate del settore, ora parte di Twilio — aveva bevuto il Kool-Aid. Avevano costruito un'architettura con oltre 140 microservizi. Ogni integrazione — ogni destinazione a cui i clienti potevano mandare i loro dati — era un servizio separato con la sua coda, il suo deployment, il suo monitoraggio.
Poi hanno fatto qualcosa di impensabile: hanno consolidato tutto in un singolo servizio. Sono tornati al monolith.
E stata una delle migliori decisioni che abbiano mai preso.
L'Architettura Iniziale
L'idea dietro l'architettura originale era sensata. Segment gestisce il routing dei dati dei clienti verso centinaia di destinazioni diverse: analytics, CRM, data warehouse, tool di marketing. Se un'integrazione ha problemi — se Salesforce e lento, se Google Analytics ha un bug — non dovrebbe impattare le altre.
La soluzione classica: ogni integrazione e un microservizio. Ha la sua coda di messaggi. Ha le sue risorse. Ha i suoi limiti di rate. Se esplode, esplode da sola.
Questo funzionava quando avevano 10 integrazioni. Funzionava ancora a 50. Ma quando sono arrivati a 140, con un team di tre ingegneri che doveva mantenere tutto, la complessita e diventata ingestibile.
I Problemi Reali
1. Overhead Operativo Lineare
Ogni nuovo servizio aggiungeva overhead: deployment, monitoraggio, alerting, on-call rotations. Con 140 servizi, il team passava piu tempo a mantenere l'infrastruttura che a migliorare il prodotto.
2. Dipendenze Divergenti
Ogni servizio aveva le sue dipendenze. Le librerie condivise esistevano in versioni diverse in repo diverse. Aggiornare una dipendenza significava aggiornarla in 140 posti, ognuno con i suoi potenziali conflitti.
3. Test Fragili
I test facevano richieste HTTP reali alle API esterne. Quando un'API cambiava il suo comportamento, decine di test fallivano. Il feedback loop per uno sviluppatore era lento e frustrante.
4. Paging Notturno
Con 140 servizi, qualcosa era sempre rotto. Il team veniva svegliato di notte per gestire spike di carico, backlog nelle code, timeout su singole integrazioni. Il burnout era reale.
La promessa dei microservizi era "isolamento dei guasti". La realta era "moltiplicazione dei guasti". Non avevano un sistema che poteva fallire in un punto — avevano 140 punti di fallimento potenziale.
La Decisione Controintuitiva
La soluzione tradizionale sarebbe stata: assumere piu persone, costruire migliori tool di orchestrazione, adottare Kubernetes. Investire nella complessita.
Segment ha fatto il contrario. Ha preso 140 servizi e li ha consolidati in uno solo. Un monolith.
Non un monolith "stupido" — un monolith progettato con cura. Il codice era organizzato in moduli puliti. Le dipendenze erano condivise e sincronizzate. I test giravano in-process invece che via HTTP. Ma era un singolo artefatto deployabile.
I Risultati
Velocita di Sviluppo
L'anno prima della migrazione, il team aveva fatto 32 miglioramenti alle librerie condivise. L'anno dopo, 46. Quasi il 50% in piu, con lo stesso team.
Tempo di Test
Prima: minuti per testare una singola destinazione. Dopo: millisecondi per testare tutte e 140. I test giravano in-memory, senza network overhead.
Operazioni
Un servizio da monitorare invece di 140. Un deployment invece di 140. Un set di metriche invece di 140. Il team poteva finalmente dormire.
Risorse
I microservizi avevano tutti bisogno di un mix di CPU e memoria, ma ogni servizio aveva carichi diversi. Alcuni erano CPU-bound, altri memory-bound. Dimensionare correttamente 140 servizi era impossibile — finivi per sprecare risorse ovunque. Un singolo servizio poteva bilanciare i carichi internamente.
I Trade-off Accettati
Il monolith non e perfetto. Segment ha accettato alcuni trade-off consapevolmente.
Isolamento dei guasti ridotto: Un bug in un'integrazione puo teoricamente crashare tutto il servizio. In pratica, con buoni test e circuit breaker, non e mai successo.
Cache in-memory meno efficace: Con microservizi, ogni servizio aveva la sua cache calda per la sua integrazione specifica. Nel monolith, la cache e condivisa e meno specializzata.
Deployment atomici: Aggiornare un'integrazione significa ridepolare tutto. Ma con buona CI/CD, questo deployment richiede minuti, non ore.
Erano trade-off accettabili per il loro contesto. Tre ingegneri che cercavano di sopravvivere erano disposti a rinunciare alla perfezione teorica in cambio della sanita mentale pratica.
Quando I Microservizi Hanno Senso
Segment non sta dicendo che i microservizi siano sempre sbagliati. Stanno dicendo che erano sbagliati per loro, in quel momento, con quel team.
I microservizi hanno senso quando:
- Hai team grandi che lavorano su parti diverse del sistema
- Le parti hanno cicli di deployment radicalmente diversi
- L'isolamento dei guasti e critico per il business
- Hai l'infrastruttura e le competenze per gestire la complessita
Netflix ha senso con i microservizi. Hanno migliaia di ingegneri, infrastruttura proprietaria, e requisiti di disponibilita estremi. Una startup con tre ingegneri non e Netflix.
La regola non scritta: I microservizi sono una soluzione a problemi di organizzazione, non di tecnologia. Se non hai problemi di coordinamento tra team, probabilmente non hai bisogno di microservizi.
Il Monolith Modulare
C'e una via di mezzo che sta guadagnando popolarita: il monolith modulare. Un singolo deployable, ma con confini interni chiari tra i moduli. Puoi avere la semplicita operativa del monolith con la separazione logica dei microservizi.
E quello che Segment ha costruito, in pratica. Non un blob di codice spaghetti, ma un sistema organizzato con interfacce pulite tra le parti. Se un giorno avranno bisogno di estrarre un pezzo come servizio separato, potranno farlo. Ma fino ad allora, godono della semplicita.
Rails, Laravel, Django — i grandi framework monolitici — stanno tutti andando in questa direzione. Moduli, bounded context, separazione delle responsabilita. Le buone pratiche dei microservizi, senza il costo operativo.
Lezioni Per Tutti
1. L'architettura deve servire il team, non il contrario. Se la tua architettura richiede piu ingegneri di quanti ne hai per essere mantenuta, e l'architettura sbagliata.
2. La complessita ha un costo composto. Ogni microservizio aggiunge un po' di overhead. Ma quegli overhead si sommano, e a un certo punto il costo totale supera i benefici.
3. Puoi sempre spacchettare dopo. E molto piu facile estrarre un servizio da un monolith che consolidare microservizi in un monolith. Se non sei sicuro, parti semplice.
4. Le best practice sono contestuali. Quello che funziona per Netflix non funziona per tutti. L'architettura giusta dipende dal team, dal prodotto, dal momento.
"Invece di abilitarci a muoverci piu velocemente, il piccolo team si e trovato sommerso dalla complessita esplodente."
Conclusione
L'industria del software e piena di mode. Microservizi, serverless, event-driven, mesh — ogni anno c'e una nuova architettura che promette di risolvere tutto. E ogni anno, team che non ne avevano bisogno la adottano perche "e quello che fanno tutti".
La storia di Segment e un promemoria salutare. A volte la soluzione giusta e la piu semplice. A volte tornare indietro e andare avanti. A volte il monolith — quello strumento "vecchio" e "poco figo" — e esattamente quello che serve.
Non scegliere l'architettura per impressionare gli altri ingegneri al prossimo meetup. Sceglila per risolvere i problemi che hai davvero, con le risorse che hai davvero, nel contesto in cui sei davvero.
A volte, meno e piu.
Fonte: Segment Engineering Blog (ora Twilio)
Dicembre 2025
