Resta sul monolite fino a 150 sviluppatori: perché i microservizi costano dal 30 al 50%

Parti dal monolite modulare come scelta predefinita. Estrai i microservizi solo quando hai una ragione concreta a livello organizzativo: un team che ha superato i 150 sviluppatori, carichi di lavoro con profili di scalabilità davvero divergenti, oppure un vincolo normativo come PCI o SOC 2 che impone l'isolamento. I microservizi portano con sé una vera tassa operativa, spesso stimata nel 30 to 50 percent of engineering capacity una volta superato il confine della rete: l'onere della prova sta quindi in capo a chi chiede di separare le cose, non a chi vuole tenerle insieme.

---

In breve:

• Passare ai microservizi costa: per gestirli serve dal 30 al 50% di capacità di sviluppo in più, soprattutto se i servizi condividono database o vengono rilasciati insieme.

• Di solito serve un team di oltre 150 sviluppatori perché i microservizi compensino davvero i costi di coordinamento, la divergenza nella scalabilità e i vincoli normativi.

• I team più piccoli, sotto i 30 sviluppatori, dovrebbero restare su architetture monolitiche o modulari: meno complessità, consegna più rapida e nessun peso operativo dei microservizi.

• Conviene migrare in modo incrementale con il pattern strangler fig, partendo dai bounded context a basso accoppiamento ed evitando di spostare troppo presto la proprietà dei dati.

• Fai una valutazione onesta dell'architettura per misurare capacità del team, maturità di CI/CD e bounded context prima di impegnarti sui microservizi o di smontare il monolite.

Indice

• Monolite o microservizi: le definizioni che ti servono prima di decidere

• Rilascio, dati e accoppiamento: dove le due strade divergono davvero

• I compromessi che si vedono davvero nei progetti reali

• Quando restare monolitici, quando passare al modulare e quando ai microservizi

• Come migrare senza costruire un monolite distribuito

• La tassa dei sistemi distribuiti: quanto ti costano davvero i microservizi

• Come Ampersand affronta questa decisione con i clienti

• Perché «prima il monolite» batte ancora le mode del settore

• Fai una valutazione onesta dell'architettura prima di dividere qualsiasi cosa

• Fonti

• FAQ

Monolite o microservizi: le definizioni che ti servono prima di decidere

Metà delle discussioni su «microservizi vs monolite» si sgonfia nel momento in cui tutti si mettono d'accordo sul significato delle parole. Un monolite classico è un'unica unità distribuibile: di solito un solo codice sorgente, una sola build, un solo database, dove ogni modulo gira nello stesso processo e condivide lo stesso schema. È il modo più rapido per portare in produzione un prodotto funzionante ed è così che è partita quasi ogni azienda software di successo.

Un monolite modulare mantiene quell'unica unità di rilascio, ma impone confini interni: i moduli comunicano attraverso interfacce definite, sono proprietari delle proprie tabelle anche dentro il database condiviso e, in teoria, potrebbero essere separati più tardi senza riscrivere tutto. Resta una cosa sola da rilasciare, una sola da monitorare e un unico modello transazionale, ma il codice non si trasforma in un groviglio mentre cresce.

I microservizi sono servizi rilasciabili in modo indipendente, ognuno proprietario del proprio archivio dati, che comunicano via rete invece che con chiamate di funzione nello stesso processo. La Microsoft’s Azure architecture guidance lo indica come il tratto distintivo: se un servizio non può andare in produzione senza coordinare un rilascio con altri tre team, non è ancora un vero microservizio.

Verifica il tuo codice rispetto a questi indicatori:

• Puoi rilasciare un singolo modulo senza ridistribuire l'intera applicazione?

• Ogni dominio è proprietario delle proprie tabelle, oppure tutto si incrocia con join sullo stesso schema?

• I moduli si chiamano tra loro con chiamate di funzione a livello di linguaggio o via HTTP/gRPC/code di messaggi?

• La tua pipeline CI/CD compila e testa il sistema come un'unica unità o come tante unità indipendenti?

Rilascio, dati e accoppiamento: dove le due strade divergono davvero

Le differenze che contano non sono filosofiche. Si vedono in quattro punti concreti: come rilasci il codice, come archivi i dati, come i componenti si parlano tra loro e come sono organizzati i team intorno a tutto questo.

Rilascio e accoppiamento delle release. Un monolite va in produzione come unità unica. Ogni modifica, che riguardi il modulo di fatturazione o la pagina di login, viaggia sulla stessa build e sullo stesso treno di rilascio. I microservizi disaccoppiano tutto questo: il team dei pagamenti può rilasciare dieci volte al giorno mentre quello del magazzino rilascia una volta a settimana, senza che nessuno dei due blocchi l'altro. Questa indipendenza è la ragione principale per cui le grandi organizzazioni cercano la separazione.

Proprietà dei dati. I monoliti di solito usano un unico database logico, il che rende banali query e transazioni fra domini: basta un join fra tabelle. I microservizi spingono verso un database per servizio, spesso con motori di archiviazione diversi per esigenze diverse (persistenza poliglotta), il che elimina i join facili e ti costringe a ragionare in termini di consistenza finale, saga e composizione di API. Microservices raccoglie in un catalogo questi pattern, perché quasi ogni team prima li reinventa a proprie spese.

Accoppiamento e modalità di guasto. Le chiamate di funzione nello stesso processo raramente falliscono e, quando lo fanno, falliscono subito. Le chiamate di rete fra servizi introducono una categoria di guasti completamente nuova: timeout, guasti parziali, tentativi ripetuti e la necessità di circuit breaker. La rete diventa parte della tua architettura, che tu l'avessi previsto o no.

Proprietà dei team e legge di Conway. È l'asse che si tende a sottovalutare. L'architettura tende a rispecchiare la struttura di comunicazione dell'organizzazione che la costruisce. Un team di 12 sviluppatori che divide un prodotto in nove servizi non sta facendo buona architettura: sta combattendo contro il proprio organigramma. La scomposizione deve seguire i confini dei team, non precederli.

I compromessi che si vedono davvero nei progetti reali

I pro e i contro di ciascun approccio non sono astratti. Colpiscono il tuo calendario, il tuo budget e i turni di reperibilità.

1. I monoliti vincono sulla velocità di arrivo sul mercato. Un solo codice sorgente, una sola pipeline di rilascio, un solo posto dove mettere un breakpoint. Fare il debug di una richiesta dall'inizio alla fine significa leggere un solo stack trace, non ricucire tracce distribuite su cinque servizi.

2. I monoliti vincono sui costi iniziali di infrastruttura. Un database, una fattura di hosting, nessuna service mesh, nessuno stack di monitoraggio per ogni servizio. Per la maggior parte delle startup questo dovrebbe già chiudere la discussione sul nascere.

3. I microservizi vincono sulla scalabilità indipendente. Se il carico di elaborazione delle immagini schizza a 50 volte il normale nelle ore di punta mentre il servizio dei profili utente resta piatto, separarli ti permette di scalare la parte costosa senza pagare per scalare tutto il resto.

4. I microservizi vincono sull'autonomia dei team e sull'isolamento dei guasti. Un motore di raccomandazione che va in crash non deve trascinarsi dietro il checkout, se sono servizi separati con domini di guasto separati.

5. Il rischio più grosso è il monolite distribuito. I servizi vengono divisi sulla carta, ma continuano a essere rilasciati insieme, condividono un database o si chiamano tra loro in modo sincrono in catene lunghe. Ti ritrovi con tutti i costi operativi dei microservizi e nessun vantaggio in termini di indipendenza.

6. La proliferazione è reale. Più servizi significa più repository, più pipeline, più dashboard e più posti in cui uno sviluppatore junior può perdersi alle 2 di notte durante un incidente.

Quando restare monolitici, quando passare al modulare e quando ai microservizi

La dimensione del team è l'indicatore più affidabile per capire quale architettura funzionerà davvero per te, più affidabile del volume di traffico e persino della complessità tecnica.

• Sotto i 30 sviluppatori circa: resta monolitico, idealmente modulare. Non hai le persone per mettere in piedi un team di piattaforma e, in ogni caso, il costo di coordinamento fra due persone è praticamente zero.

• Fra i 30 e i 150 sviluppatori circa: per la maggior parte dei team è il territorio del monolite modulare, con l'estrazione selettiva di uno o due servizi che hanno un profilo di scalabilità davvero diverso o un vincolo normativo rigido.

• Oltre i 150 sviluppatori circa: i microservizi iniziano a ripagarsi, perché il costo di coordinamento di decine di team che rilasciano su un unico treno supera il costo di gestire un'infrastruttura distribuita. The HLD Handbook lo inquadra come un pattern organizzativo tanto quanto tecnico.

Oltre al numero di persone, tre segnali legati al carico di lavoro indicano che l'estrazione vale la pena: esigenze di scalabilità divergenti fra i componenti, requisiti di latenza molto diversi da funzione a funzione e traffico a picchi che ti costringerebbe a sovradimensionare tutto il monolite solo per gestire un unico percorso critico.

L'isolamento normativo è l'altro innesco legittimo. Se il perimetro PCI DSS o i confini SOC 2 impongono che i dati di pagamento non tocchino mai lo stesso processo o lo stesso segmento di rete di tutto il resto, quello è un vincolo architetturale reale, non una preferenza.

Prima di estrarre qualsiasi cosa, passa questa checklist di prontezza:

• Hai un team di piattaforma, anche piccolo, dedicato all'infrastruttura condivisa?

• La tua pipeline CI/CD è automatizzata abbastanza da sostenere rilasci indipendenti senza controlli manuali?

• Hai una vera osservabilità: tracciamento distribuito, log centralizzati e dashboard per singolo servizio?

• I tuoi bounded context sono davvero chiari o stai tirando a indovinare su dove passano le linee di taglio?

Consiglio: Se non riesci a rispondere «sì» ad almeno tre di queste quattro domande, nei primi sei mesi l'estrazione ti costerà più di quanto ti faccia risparmiare. Prima colma le lacune di prontezza, oppure resta modulare ancora per un po'.

Come migrare senza costruire un monolite distribuito

Quasi tutte le migrazioni a microservizi riuscite started as a monolith e sono avanzate pezzo per pezzo, mai come riscrittura da zero. Il pattern strangler fig è l'approccio standard e funziona perché non ti chiede mai di scommettere l'azienda su un passaggio big bang.

1. Metti un livello di routing davanti al monolite. Un API gateway o un reverse proxy si posiziona fra i client e il tuo sistema e all'inizio inoltra il 100% del traffico al monolite esistente.

2. Scegli un solo bounded context da estrarre per primo. Prendi qualcosa con basso accoppiamento verso il resto del sistema, con un team proprietario chiaro e con esigenze di dati che non richiedono join continui con altri domini. Le notifiche o la ricerca sono candidati frequenti; la fatturazione centrale quasi mai.

3. Costruisci il nuovo servizio e fallo girare in parallelo. Instrada una fetta di traffico verso il nuovo servizio mentre il monolite gestisce ancora il resto e confronta i risultati prima di passare del tutto.

4. Sposta la proprietà dei dati per ultima, non per prima. Tieni il database del monolite come fonte di verità finché il nuovo servizio non si è dimostrato stabile, poi trasferisci la proprietà e recupera i dati storici.

5. Ripeti, un bounded context alla volta, dismettendo il codice del monolite man mano che ogni estrazione si stabilizza.

Fai attenzione all'anti-pattern che tutto il settore continua a riscoprire: servizi «indipendenti» sul diagramma dell'architettura, ma che in pratica devono essere rilasciati tutti insieme. La regola pratica di The HLD Handbook è brutale: conta quanti servizi devono andare in produzione in blocco per un singolo rilascio. Se sono la maggior parte, hai costruito un monolite distribuito e faresti meglio a consolidare. I test di contratto fra servizi e i feature flag durante il rollout intercettano la maggior parte delle regressioni prima che arrivino in produzione.

La tassa dei sistemi distribuiti: quanto ti costano davvero i microservizi

Superare il confine di processo non è gratis e il conto è più salato di quanto la maggior parte dei team metta a budget. La stima di The HLD Handbook colloca la tassa dei sistemi distribuiti intorno al 30-50% della capacità di sviluppo quando hai microservizi in produzione: una cifra che comprende gli strumenti di osservabilità, la disciplina di versionamento attraverso i confini dei servizi e il peso della reperibilità per fare il debug di guasti che attraversano cinque servizi invece di un solo stack trace.

Questa tassa si vede in voci di costo precise:

• Pipeline CI/CD per ogni servizio invece di una sola pipeline condivisa.

• Tracciamento distribuito e log centralizzati, perché «guarda i log» ora significa controllare cinque flussi di log diversi.

• Una funzione di piattaforma o SRE dedicata a infrastruttura condivisa, service mesh e strumenti di rilascio.

• Pattern saga e outbox per gestire transazioni che prima erano un singolo commit sul database.

Esistono contromisure, soprattutto l'ingegneria di piattaforma che automatizza le parti ripetitive e i pattern di osservabilità integrati dal primo giorno invece di aggiunti dopo un blocco del servizio. Gli strumenti che si occupano del lavoro operativo di routine possono assorbire una parte di quella tassa, ma non la eliminano. Se il tuo team non è in grado di sostenere quell'investimento continuo in piattaforma, la risposta onesta è restare monolitici, o modulari, finché non lo sarà.

Come Ampersand affronta questa decisione con i clienti

Un team di sviluppo senior tratta questa come una domanda prima organizzativa e poi tecnica, perché è lì che la maggior parte delle decisioni di estrazione va storta. In un progetto per un cliente con una piattaforma in crescita e decine di strumenti interni, l'approccio è stato consolidare intorno a un'architettura modulare invece di frammentare in servizi che il team non aveva le persone per gestire. Il coinvolgimento di figure senior già dalla prima conversazione ha fatto emergere il rischio di migrazione prima che venisse scritto del codice, non dopo una riscrittura arenata. Il supporto mensile continuativo ha poi mantenuto il sistema in salute senza richiedere un team di piattaforma dedicato che il cliente non aveva.

Perché «prima il monolite» batte ancora le mode del settore

La saggezza comune su questo tema è stata distorta dal bias del sopravvissuto. Tutti si ricordano Netflix e Amazon che parlano di microservizi alle conferenze; nessuno si ricorda le centinaia di team che hanno copiato quell'architettura senza avere il traffico, le persone o l'investimento in piattaforma per sostenerla. Amazon non è nata a microservizi. Lo è diventata dopo anni di dolori di crescita del monolite, e solo quando la sua organizzazione aveva davvero superato la misura di un'unica unità di rilascio.

Lo scarto che continuo a vedere è fra quello che i microservizi promettono e quello che i team sono realmente attrezzati a gestire. Una startup di 20 persone che adotta nove servizi non sta comprando scalabilità: sta comprando nove cose da tenere aggiornate, monitorate e sotto reperibilità, di solito senza nessuno il cui lavoro sia esclusivamente quello. La tassa dei sistemi distribuiti non chiede il permesso. Si manifesta in consegne di funzionalità più lente entro due trimestri, quasi ogni volta.

Se devi portarti a casa una cosa sola: usa la dimensione del team e la maturità organizzativa come criterio di sbarramento, non l'entusiasmo per il pattern. Un monolite modulare non è un premio di consolazione. Per la maggior parte delle aziende è semplicemente l'architettura corretta, a tempo indeterminato.

Fai una valutazione onesta dell'architettura prima di dividere qualsiasi cosa

Ampersand Labs è l'alternativa al tirare a indovinare in una decisione di estrazione: sviluppatori senior esaminano il tuo codice reale e la struttura del tuo team prima di consigliare qualsiasi cosa, invece di ripiegare sull'architettura più di moda. È importante, perché il costo di sbagliare qui non è teorico. I team che estraggono troppo presto passano l'anno successivo a pagare la tassa dei sistemi distribuiti invece di rilasciare funzionalità.

Una valutazione dell'architettura può guardare i tuoi bounded context, la maturità della tua CI/CD e la reale capacità del tuo team di occuparsi del lavoro di piattaforma, per poi consigliare la costruzione di un monolite modulare, una migrazione delimitata o un'estrazione di servizi mirata dove i dati la giustificano davvero. Per i team che hanno già superato quella soglia, un supporto mensile continuativo può coprire il carico operativo creato dai microservizi senza obbligarti ad assumere un team di piattaforma completo. Il coinvolgimento di figure senior già dalla prima chiamata significa avere una risposta chiara sull'opportunità di dividere qualcosa. Parti da un audit tecnico o da una breve chiamata conoscitiva per capire dove si trova davvero la tua architettura.

Fonti

• started as a monolith

• 30 to 50 percent of engineering capacity

• Microsoft’s Azure architecture guidance

• Microservices

FAQ

I monoliti sono meglio dei microservizi?

Nessuno dei due è migliore in assoluto. I monoliti tendono a vincere per team piccoli e prodotti nelle prime fasi, mentre i microservizi ripagano quando un'organizzazione ha superato la misura di un unico treno di rilascio e può dedicare persone al lavoro di piattaforma necessario.

Amazon è monolitica o a microservizi?

Oggi Amazon gira su microservizi, ma è partita come monolite ed è migrata in modo incrementale nel corso di anni, mentre la sua organizzazione tecnica e il traffico crescevano, non come scelta di progetto del primo giorno.

Qual è un esempio di monolite?

Una tipica applicazione di e-commerce con un solo codice sorgente che gestisce catalogo prodotti, checkout e account utente su un unico database condiviso è un monolite classico, ed è così che inizia la maggior parte dei prodotti di successo.

Quali sono i tre tipi di microservizi?

I microservizi vengono di solito raggruppati per funzione: servizi di dominio che possiedono una logica di business specifica (come fatturazione o magazzino), servizi di integrazione che si collegano a sistemi esterni e servizi di infrastruttura o piattaforma (come un API gateway) che supportano gli altri.

Quando una startup dovrebbe scegliere un monolite modulare invece dei microservizi?

La maggior parte dei team sotto i 30 sviluppatori circa dovrebbe partire da un monolite modulare, perché raramente ha le persone da dedicare al lavoro di piattaforma e osservabilità che i microservizi richiedono.

Consigliati

• Atelier Crincoli: l'intero laboratorio di un orafo in un unico sistema, così non si perde nessun pezzo e nessuna scadenza.

• CTO ad interim a Zurigo, responsabile tecnico frazionale e a tempo parziale

• Habitects AG: la parte tecnica di una piattaforma per ristrutturazioni di bagni, gestita fino alla fusione.

• Migrazione di sistemi legacy e replatforming a Zurigo