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

Parti da un monolite modulare come scelta predefinita. Estrai microservizi solo quando hai un motivo concreto a livello di organizzazione: un team cresciuto oltre le 150 persone circa, carichi di lavoro con profili di scalabilità davvero divergenti, oppure un confine normativo come PCI o SOC 2 che impone l’isolamento. I microservizi comportano una tassa operativa reale, 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 dividere, non a chi vuole tenere tutto insieme.

---

In breve:

• Passare ai microservizi costa caro: per gestirli serve dal 30 al 50 per cento di capacità di sviluppo in più, soprattutto se i servizi condividono i database o vengono rilasciati insieme.
• Di solito serve un team di oltre 150 persone perché i microservizi compensino davvero i costi di coordinamento, la divergenza nella scalabilità e i vincoli normativi.
• I team sotto le 30 persone dovrebbero restare su architetture monolitiche o modulari: meno complessità, consegne più rapide e nessun peso operativo dei microservizi.
• Meglio migrare in modo incrementale con lo strangler fig pattern, partendo dai bounded context poco accoppiati ed evitando di spostare troppo presto la proprietà dei dati.
• Prima di impegnarti sui microservizi o di smontare un monolite, fai una valutazione onesta dell’architettura: capacità del team, maturità della CI/CD e chiarezza dei bounded context.

Indice

• Monolite vs microservizi: le definizioni da chiarire prima di decidere
• Rilascio, dati e accoppiamento: dove i due approcci divergono davvero
• I compromessi che si vedono davvero nei progetti reali
• Quando restare monolitici, passare al modulare o adottare i 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 l’hype del settore
• Fatti valutare l’architettura in modo onesto prima di dividere qualcosa
• Fonti
• FAQ

Monolite vs microservizi: le definizioni da chiarire prima di decidere

Metà delle discussioni su “microservizi vs monolite” si sgonfia appena ci si mette d’accordo sul significato delle parole. Un monolite classico è una singola unità rilasciabile: di solito un codebase, una build, un 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à rilasciabile, ma impone confini interni: i moduli si parlano attraverso interfacce definite, possiedono le proprie tabelle anche dentro il database condiviso e in teoria potrebbero essere separati in seguito senza riscrivere tutto. Resta una cosa sola da rilasciare, una sola da monitorare e un solo modello transazionale, ma il codice non diventa un groviglio mentre cresce.

I microservizi sono servizi rilasciabili in modo indipendente, ognuno proprietario del proprio archivio dati, che comunicano via rete e non con chiamate di funzione nello stesso processo. Microsoft’s Azure architecture guidance indicano proprio questo come il tratto distintivo: se un servizio non può essere rilasciato senza coordinare una release con altri tre team, non è ancora un vero microservizio.

Verifica il tuo codebase rispetto a questi indicatori:

• Puoi rilasciare un modulo senza rimettere in produzione l’intera applicazione?
• Ogni dominio possiede le proprie tabelle, oppure tutto si incrocia sullo stesso schema?
• I moduli si chiamano tra loro con chiamate di funzione del linguaggio, oppure via HTTP/gRPC/code di messaggi?
• La tua pipeline CI/CD costruisce e testa il sistema come un’unica unità o come tante unità indipendenti?

Rilascio, dati e accoppiamento: dove i due approcci divergono davvero

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

Rilascio e accoppiamento delle release. Un monolite viene rilasciato come un’unica unità. Ogni modifica, che tocchi il modulo di fatturazione o la pagina di login, viaggia sulla stessa build e sullo stesso ciclo di rilascio. I microservizi disaccoppiano tutto questo: il team pagamenti può rilasciare dieci volte al giorno mentre il team magazzino rilascia una volta a settimana, e nessuno dei due blocca l’altro. Questa indipendenza è il motivo principale per cui le grandi organizzazioni scelgono di dividere.

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

Accoppiamento e modalità di guasto. Le chiamate di funzione nello stesso processo falliscono raramente e falliscono subito. Le chiamate di rete tra 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’abbia previsto o no.

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

I compromessi che si vedono davvero nei progetti reali

I pro e i contro dei due approcci non sono astratti. Colpiscono il tuo calendario, il tuo budget e i tuoi turni di reperibilità.

1. I monoliti vincono sulla velocità di arrivo sul mercato. Un solo codebase, una sola pipeline di rilascio, un solo posto dove mettere un breakpoint. Fare il debug di una richiesta dall’inizio alla fine significa leggere uno stack trace, non ricomporre tracce distribuite su cinque servizi.
2. I monoliti vincono sul costo iniziale dell’infrastruttura. Un database, una fattura di hosting, nessuna service mesh, nessuno stack di monitoraggio per servizio. Per la maggior parte delle startup questo dovrebbe già chiudere il dibattito 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 su autonomia dei team e isolamento dei guasti. Un motore di raccomandazione che va in crash non deve per forza far cadere anche il checkout, se sono servizi separati con domini di guasto separati.
5. Il rischio più grande è il monolite distribuito. Sulla carta i servizi sono divisi, ma nella pratica vengono rilasciati insieme, condividono un database o si chiamano a vicenda in modo sincrono in lunghe catene. Ti prendi tutto il costo operativo dei microservizi senza nessuno dei benefici dell’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 due di notte durante un incidente.

Quando restare monolitici, passare al modulare o adottare i 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 le 30 persone circa: resta monolitico, possibilmente modulare. Non hai l’organico per mettere in piedi un team di piattaforma e, tanto, il costo di coordinamento tra due persone è praticamente zero.
• Tra le 30 e le 150 persone circa: per la maggior parte dei team è territorio da monolite modulare, con l’estrazione selettiva di uno o due servizi che hanno un profilo di scalabilità davvero diverso o un confine normativo rigido.
• Oltre le 150 persone circa: i microservizi iniziano a ripagarsi, perché il costo di coordinamento di decine di team che rilasciano attraverso un unico ciclo di rilascio supera il costo di gestire un’infrastruttura distribuita. The HLD Handbook lo inquadra come un pattern organizzativo tanto quanto tecnico.

Oltre all’organico, tre segnali legati al carico di lavoro suggeriscono che l’estrazione ne valga la pena: esigenze di scalabilità divergenti tra i componenti, requisiti di latenza molto diversi da funzione a funzione e traffico a picchi che ti costringerebbe a sovradimensionare l’intero monolite solo per gestire un singolo percorso critico.

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

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

• Hai un team di piattaforma, anche piccolo, dedicato all’infrastruttura condivisa?
• La tua pipeline CI/CD è abbastanza automatizzata da reggere rilasci indipendenti senza controlli manuali?
• Hai un’osservabilità vera: tracciamento distribuito, log centralizzati e dashboard per singolo servizio?
• I tuoi bounded context sono davvero chiari, o stai tirando a indovinare 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, 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. Lo strangler fig pattern è l’approccio standard e funziona proprio perché non ti chiede mai di scommettere l’azienda su un passaggio in blocco.

1. Metti un livello di instradamento davanti al monolite. Un API gateway o un reverse proxy si posiziona tra i client e il tuo sistema, inoltrando all’inizio il 100% del traffico al monolite esistente.
2. Scegli un solo bounded context da estrarre per primo. Prendi qualcosa con basso accoppiamento rispetto al resto del sistema, con un team proprietario chiaro e con esigenze di dati che non richiedono join continue con altri domini. Notifiche o 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, ritirando il codice del monolite man mano che ogni estrazione si stabilizza.

Attenzione all’anti-pattern che tutto il settore continua a riscoprire: servizi “indipendenti” sul diagramma dell’architettura che però nella pratica devono essere rilasciati tutti insieme. La regola pratica di The HLD Handbook è netta: conta quanti servizi devono essere rilasciati in blocco per una data release. Se sono la maggior parte, hai costruito un monolite distribuito e faresti meglio a riunificare. I test di contratto tra servizi e i feature flag durante il rollout intercettano gran parte delle regressioni prima che arrivino in produzione.

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

Attraversare il confine del 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 attorno al 30-50% della capacità di sviluppo quando hai microservizi in produzione, una cifra che comprende gli strumenti di osservabilità, la disciplina sul versionamento fra i confini dei servizi e il peso della reperibilità quando devi analizzare guasti che attraversano cinque servizi invece di un solo stack trace.

Quella tassa si presenta sotto forma di voci di spesa 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 all’infrastruttura condivisa, alla service mesh e agli strumenti di rilascio.
• Pattern saga e outbox per gestire transazioni che prima erano un singolo commit sul database.

Delle contromisure esistono, soprattutto una vera ingegneria di piattaforma che automatizza le parti ripetitive e schemi di osservabilità previsti fin dal primo giorno invece che aggiunti dopo un guasto. 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 può sostenere quell’investimento continuo in piattaforma, la risposta onesta è restare monolitici, o modulari, finché non potrai permettertelo.

Come Ampersand affronta questa decisione con i clienti

Un team di sviluppo senior tratta questa come una questione prima organizzativa e poi tecnica, perché è lì che la maggior parte delle decisioni di estrazione va storta. In un progetto per un cliente, una piattaforma in crescita con decine di strumenti interni, l’approccio è stato consolidare attorno a un’architettura modulare invece di frammentare in servizi che il team non aveva le persone per gestire. Il coinvolgimento di figure senior fin dalla prima conversazione ha fatto emergere il rischio di migrazione prima che venisse scritta una riga di codice, non dopo che una riscrittura si era 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 l’hype del settore

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

Lo scarto che continuo a vedere è tra ciò che i microservizi promettono e ciò che i team hanno davvero le persone per gestire. Una startup di 20 persone che adotta nove servizi non sta comprando scalabilità, sta comprando nove cose da tenere aggiornate, monitorate e in reperibilità, di solito senza nessuno il cui lavoro sia esclusivamente questo. La tassa dei sistemi distribuiti non chiede il permesso: si manifesta con consegne più lente entro due trimestri, quasi ogni volta.

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

, Davide Morotti

Fatti valutare l’architettura in modo onesto prima di dividere qualcosa

Ampersand Labs è l’alternativa al tirare a indovinare su una decisione di estrazione: sviluppatori senior esaminano il tuo codebase reale e la struttura del tuo team prima di consigliare qualsiasi cosa, invece di ripiegare sull’architettura di moda. Conta, 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 ai tuoi bounded context, alla maturità della tua CI/CD e alla reale capacità del tuo team di occuparsi di lavoro di piattaforma, per poi consigliare la costruzione di un monolite modulare, una migrazione circoscritta oppure un’estrazione mirata di servizi dove i dati la giustificano davvero. Per i team che quel punto lo hanno già superato, un supporto mensile continuativo può coprire il carico operativo creato dai microservizi senza costringerti ad assumere un team di piattaforma completo. Il coinvolgimento di figure senior fin dalla prima chiamata significa che avrai una risposta chiara sul fatto che ti serva davvero dividere qualcosa. Inizia con un audit tecnico o una breve chiamata conoscitiva per capire a che punto sei davvero con 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 è meglio in assoluto. I monoliti tendono a vincere per team piccoli e prodotti nelle fasi iniziali, mentre i microservizi ripagano quando un’organizzazione ha superato la dimensione di un unico ciclo di rilascio e può dedicare persone al lavoro di piattaforma necessario.

Amazon è monolitica o a microservizi?

Oggi Amazon funziona a microservizi, ma è nata come monolite ed è migrata in modo incrementale nell’arco di anni, mentre crescevano la sua organizzazione tecnica e il traffico, non per una scelta di progettazione fatta il primo giorno.

Qual è un esempio di monolite?

Una tipica applicazione di e-commerce con un solo codebase che gestisce catalogo prodotti, checkout e account utente su un unico database condiviso è un monolite classico, ed è così che iniziano quasi tutti i prodotti di successo.

Quali sono i tre tipi di microservizi?

I microservizi si raggruppano di solito 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 le 30 persone circa dovrebbe partire da un monolite modulare, perché raramente ha l’organico per coprire il lavoro di piattaforma e di osservabilità che i microservizi richiedono.

Consigliati

• Atelier Crincoli: tutto il laboratorio di un orafo in un unico sistema, così non si perdono né pezzi né scadenze.
• CTO ad interim a Zurigo, guida tecnica frazionale e part-time
• Habitects AG: la responsabilità tecnica di una piattaforma per ristrutturare bagni, fino a una fusione.
• Migrazione di sistemi legacy e replatforming a Zurigo