Microservizi vs Monolite: la trappola che i talk nascondono

Luca ha 7 anni di esperienza in C#. Quattro sistemi ASP.NET Core in produzione.

La scorsa settimana ha proposto microservizi per il nuovo progetto del cliente.

Il cliente ha detto sì. Luca ha esultato.

Diciotto mesi dopo, il progetto e in ritardo. I costi su Azure sono quattro volte il budget previsto.

Il team di sei persone sta gestendo Kubernetes, un service mesh (infrastruttura che gestisce automaticamente la comunicazione tra microservizi) e quattro pipeline CI/CD separate per un sistema che ha 300 utenti attivi.

Luca non ha sbagliato per incompetenza: ha sbagliato perché il mercato tech ha un problema strutturale che nessuno gli ha mai spiegato.

Il problema si chiama conference-bias: la tendenza a copiare le architetture di Netflix, Amazon e Spotify senza averne né i problemi né le risorse.

I talk che circolano online mostrano le soluzioni di chi ha già diecimila ingegneri che non riescono a lavorare insieme sullo stesso codice.

Non mostrano il conto operativo reale, i mesi di produttività ridotta per imparare Kubernetes, né le decine di aziende che hanno consolidato tutto in un monolite dopo anni di battaglia.

Il conference-bias funziona perché chi ha fallito con i microservizi non ci fa un talk.

Devo dirti una cosa scomoda: la risposta corretta per il tuo progetto probabilmente non è nei microservizi né nel monolite.

È nella struttura del tuo team è nei carichi di lavoro che hai oggi, non in quelli che immagini di avere tra tre anni.

In 25 anni di lavoro su sistemi entreprise per Sole24Ore, NATO, FIAT e GSK, ho visto questa storia ripetersi decine di volte.

Il team adotta microservizi per le motivazioni sbagliate, accumula complessità che non sa gestire, e 18 mesi dopo consolida tutto in un Modular Monolith che avrebbe dovuto costruire dall'inizio.

Questo articolo ti dai cinque segnali concreti che distinguono i casi in cui i microservizi salvano il progetto da quelli in cui lo affondano, e perché il Modular Monolith è la risposta che il 70% dei team italiani cerca senza saperlo.

Architettura monolitica vs microservizi: il mito Netflix che nessuno smonta alle conferenze

Hai imparato a progettare software guardando talk di conferenze. Lo fa quasi ogni sviluppatore serio.

I talk più visti degli ultimi dieci anni parlano di come Netflix, Amazon e Spotify hanno risolto i loro problemi di scala con i microservizi.

Ed è esattamente per questo che il 70% dei team italiani ha adottato architetture che non erano adatte alla propria situazione, e ora paga prezzi che non aveva calcolato.

La maggior parte degli sviluppatori crede che i microservizi siano l'evoluzione naturale del monolite, la scelta matura per chi vuole fare le cose per bene.

In realtà, Netflix non ha scelto i microservizi perché sono migliori.

Li ha scelti perché aveva un problema specifico: decine di team indipendenti che si bloccavano a vicenda, centinaia di milioni di utenti, requisiti di disponibilità che il monolite non reggeva più.

Il 99% delle aziende italiane che sviluppa software non ha quel problema.

Applicare l'architettura di Netflix a questi contesti non è fare le cose per bene. È over-engineering puro che aumenta la complessità senza nessun beneficio reale.

Il meccanismo del conference-bias (tendenza a prendere decisioni tecniche influenzate da ciò che va di moda, invece che dai bisogni reali del progetto.) è semplice: i talk che senti alle conferenze mostrano quasi sempre i successi.

Chi ha perso 18 mesi su microservizi sbagliati, di solito non ci fa un talk.

Questo crea una distorsione sistematica: senti solo le architetture che hanno funzionato, nel contesto in cui hanno funzionato, per i problemi che quei team avevano.

Non senti mai i fallimenti.

Il risultato è una percezione falsata dei benefici reali rispetto ai costi reali.

Nel 2023 Amazon stessa ha consolidato un sistema distribuito di Prime Video in un'unica applicazione monolitica, riducendo i costi del 90%.

Non è un caso isolato: è il sintomo di un problema sistemico.

I pattern architetturali software vengono scelti in base al marketing e ai conference talk, non in base alle esigenze reali del progetto.

Martin Fowler, uno dei teorici che ha contribuito a formalizzare i microservizi, ha scritto esplicitamente che il consiglio di default dovrebbe essere di non usarli.

Sam Newman, autore del libro di riferimento sui microservizi, ha dichiarato in più occasioni che molti team li adottano senza avere le basi organizzative e tecniche per gestirli.

Il risultato e quello che lui chiama distributed monolith: tutti i problemi dei microservizi senza nessuno dei benefici.

Il mercato italiano ha un problema specifico: molte software house adottano architetture enterprise senza valutare se hanno senso per il volume di traffico, la dimensione del team e le competenze disponibili localmente.

Questo porta a sistemi inutilmente complessi, difficili da mantenere, e costosissimi da operare.

Architettura monolitica: cos'è, i tre tipi che esistono e quale evitare

Monolite non significa codice scritto male.

Nel 2026 esistono tre tipi di monolite con caratteristiche profondamente diverse, e confonderli e l'errore che porta i team a migrare verso i microservizi per le motivazioni sbagliate:

Il monolite distribuito non è costituito da microservizi mal implementati.

È un'architettura separata, genuinamente peggiore del monolite tradizionale per qualsiasi scopo. E purtroppo e il risultato più comune quando i team adottano i microservizi senza i segnali giusti.

Stack Overflow, uno dei siti più trafficati del mondo per i sviluppatori, ha gestito miliardi di richieste al mese con un monolite per anni.

La semplicità operativa non è un deficit: e un vantaggio competitivo per qualsiasi team che vuole muoversi velocemente.

Cosa sono i microservizi: definizione, bounded context e i tre criteri che contano

Un microservizio è un servizio autonomo responsabile di un bounded context, che può essere pubblicato, scalato e sviluppato indipendentemente dagli altri servizi del sistema.

Ma cosa è un bounded context?

Immagina di lavorare in un'azienda che vende scarpe. La parola "prodotto" significa cose diverse a seconda di chi la usa:

• Per il magazzino è un paio di scarpe fisico con una posizione sullo scaffale
• Per il marketing è qualcosa con un nome, una foto e una descrizione
• Per la fatturazione è una voce con un prezzo e un'aliquota IVA

Un bounded context è semplicemente il reparto. Ognuno usa la stessa parola, ma con il suo significato specifico, senza creare confusione con gli altri.

La parola chiave non è micro. Non intesa come piccolo. In questo caso significa indipendente.

Un servizio è un vero microservizio se soddisfa tre criteri:

• Deploy indipendente: può essere rilasciato in produzione senza coordinamento con altri team o servizi. Se devi avvisare altri tre team e aspettare che siano tutti pronti, non hai microservizi: hai un monolite distribuito camuffato.
• Scalabilità indipendente: può essere scalato orizzontalmente senza dover scalare tutto il resto del sistema.
• Sviluppo indipendente: un team separato può lavorarci senza dipendere dagli altri.

Il confine di un microservizio dovrebbe corrispondere a un bounded context del dominio secondo i principi del Domain-Driven Design (approccio alla progettazione del software in cui la struttura del codice rispecchia il dominio del business).

Non si tratta di dividere il sistema per funzionalità tecniche, ma per concetti del dominio: ordini, inventario, pagamenti, notifiche.

Dividere per funzionalità tecniche invece che per dominio produce nanoservice architecture: servizi troppo piccoli con chiamate di rete così frequenti da annullare qualsiasi beneficio dell'indipendenza.

Capire dove tracciare i confini dei bounded context richiede competenze di Domain-Driven Design che vanno ben oltre la conoscenza tecnica.

È la differenza tra chi progetta sistemi e chi implementa funzionalità.

Questa differenza di competenza e esattamente ciò che separa un senior sviluppatori da un Architetto Software e non si acquisisce guardando tutorial su YouTube.

Non sto dicendo che il tuo sistema abbia già un problema architetturale.

Sto dicendo che ogni sprint speso a gestire complessità che non produce valore per il cliente è tempo che non torna.

E che la differenza tra chi sa dove sta e chi lo scopre a caro prezzo si vede sempre, ma di solito si vede tardi.

Quando usare i microservizi: 5 segnali concreti che il monolite non basta più

I microservizi non si scelgono per motivazioni filosofiche o perché è quello che fanno le aziende tech moderne.

Si scelgono quando esistono segnali concreti nel tuo progetto che indicano un problema reale che solo i microservizi risolvono meglio del monolite.

Se i segnali non ci sono, non ci sono i microservizi: non importa cosa ha fatto Netflix.

1: team multipli che si bloccano a vicenda costantemente

Se hai quattro team che lavorano sullo stesso codice e si intralciano continuamente, con conflitti di merge quotidiani, deployment bloccati perché un team non e pronto, e riunioni continue per coordinare le release, stai pagando il costo organizzativo del monolite senza il beneficio della sua semplicità.

Il principio di Conway dice che l'architettura del software tende a rispecchiare la struttura organizzativa.

La domanda è: i team si bloccano a vicenda?

Se la risposta è sì, il costo organizzativo del monolite sta superando i suoi benefici ed è il momento di considerare i microservizi.

Se la risposta è no, il monolite funziona e non c'è motivo di complicare l'architettura.

2: requisiti di scalabilita radicalmente diversi tra componenti

Se il componente di ricerca riceve 500 richieste al secondo mentre l'area amministrativa ne riceve 2, e queste differenze sono stabili e confermate dalla produzione, estrarre il motore di ricerca come servizio separato ha senso economico.

Ma attenzione: questo segnale è valido solo quando i requisiti di scalabilita sono davvero radicalmente diversi e confermati da dati reali, non da stime ipotetiche sul futuro.

3: tecnologie incompatibili necessarie per componenti diversi

Se hai bisogno di Python con TensorFlow per il componente di machine learning, di .NET per il backend principale, e magari di Go per un componente ad alta concorrenza, i microservizi sono la risposta naturale.

All'interno di un monolite .NET non puoi integrare un modulo Python in modo nativo.

4: isolamento regolatorio o di conformità

In settori come finanza, salute o telecomunicazioni, alcune funzionalità devono essere fisicamente isolate per motivi di conformità.

Il sistema di pagamenti deve essere certificato PCI-DSS separatamente dal resto.

In questi casi, i microservizi non sono una scelta architetturale opzionale, ma un requisito regolatorio concreto.

5: resilienza differenziata con isolamento dei guasti

Se un componente deve continuare a funzionare anche quando altri componenti del sistema sono down, i microservizi permettono di isolare i guasti.

In un monolite, se il processo crasha per un bug in un modulo, tutto il sistema va offline.

Con i microservizi, un servizio che crasha non abbatte gli altri.

Architettura monolitica: 5 condizioni in cui batte i microservizi

Esistono segnali altrettanto concreti che indicano che il monolite non solo va bene oggi, ma continuerà ad andare bene nel futuro prevedibile del tuo progetto.

Riconoscerli ti salva da anni di complessità operativa inutile.

1: team piccolo o singolo team

Sotto i 10-15 sviluppatori che lavorano allo stesso sistema, i microservizi aggiungono complessità senza benefici organizzativi.

Un singolo team con un monolite ben strutturato può muoversi molto più velocemente di un team che deve gestire pipeline separate, versioni multiple delle API e il meccanismo con cui i servizi si trovano a vicenda.

Tutto questo per ogni singolo modulo.

2: dominio ancora in evoluzione e non stabilizzato

Se stai costruendo un nuovo prodotto e il dominio non è ancora chiaro, dividere in microservizi presto e pericoloso.

I bounded context cambieranno con la comprensione del dominio.

Rinegoziare i confini tra microservizi in produzione e doloroso e costoso.

3: team senza esperienza operativa distribuita

Gestire un sistema a microservizi richiede competenze specifiche: supervisionare i container, far comunicare i servizi tra loro, tracciare cosa succede quando una richiesta attraversa decine di servizi, e gestire i guasti parziali senza che si propaghino a cascata.

Se il team non ha questa esperienza, il costo di acquisirla nel contesto di un sistema in produzione e enorme.

4: budget operativo limitato

Il mantenimento della gestione operativa dei microservizi costa di più.

Piu pipeline CI/CD, più ambienti di staging (ambienti di test che replicano la produzione), più risorse di computing per i container, più costi di rete tra servizi.

Per una startup o una software house italiana di medie dimensioni, questi costi non sono trascurabili.

5: sistema con requisiti di transazionalita forte

Se il dominio richiede transazioni distribuite frequenti, come nel caso di sistemi ERP, contabilità o processi di approvazione multi-step, il monolite semplifica enormemente la gestione della consistenza.

In un sistema distribuito le transazioni che coinvolgono più servizi sono molto più complesse da gestire e richiedono approcci specifici per garantire che i dati rimangano coerenti.

Leggere i segnali e necessario ma non sufficiente.

Il percorso da Corso Architetto Software AI lavora sul codice e sull'architettura del tuo progetto concreto, non su demo astratte.

Un passaggio da senior a architect vale 15.000-25.000 euro in più all'anno.

Non stai pagando un corso: stai anticipando un differenziale salariale che si ripaga in settimane.

C'è chi arriva a questo punto dell'articolo e si dice "ci devo pensare".

C'è chi si dice "devo capire esattamente dove sono prima che diventi un problema".

Solo uno dei due ha già risolto la questione.

Modular Monolith: cos'è e perché è la scelta migliore tra monolite e microservizi

Tra il monolite tradizionale e i microservizi esiste uno spazio intermedio che risolve la maggior parte dei problemi reali con una frazione della complessità.

Si chiama Modular Monolith, ed è la soluzione che il 70% dei team italiani dovrebbe scegliere ma che spesso viene ignorata perché non fa notizia alle conferenze.

Nessuno fa un talk sul Modular Monolith, ed è esattamente per questo che e la scelta corretta per la maggior parte dei contesti.

Le conferenze promuovono complessità perché è interessante da raccontare. La semplicità funzionante e noiosa da presentare ma preziosa da operare.

Un Modular Monolith e un singolo artefatto rilasciabile diviso internamente in moduli con confini espliciti.

Ogni modulo ha la propria area del database (schema separato, non database separato), la propria API pubblica verso gli altri moduli tipicamente definita come interfacce C# o eventi interni, e confini che impediscono l'accesso diretto alle entità interne degli altri moduli.

La differenza concreta tra i tre approcci, in una riga per ciascuno:

Ho lavorato con un tech lead di Bologna, otto anni di esperienza .NET, che gestiva un SaaS (software accessibile via internet come servizio, senza doverlo installare) per il settore manifatturiero.

Aveva iniziato la migrazione verso i microservizi basandosi sui consigli di un consulente che aveva visto il sistema solo per tre giorni.

In quattro mesi, il team di cinque persone aveva un cluster Kubernetes, tre servizi separati e un costo operativo su Azure di 2.200 euro al mese invece di 400.

Nessun cliente nuovo, nessuna funzionalità aggiuntiva.

Solo più complessità.

Il consolidamento in un Modular Monolith ha riportato i costi a 500 euro al mese e ha liberato due sprint al mese di sviluppo che prima andavano in gestione dell'infrastruttura.

Il Modular Monolith non è una soluzione temporanea in attesa dei veri microservizi.

E un'architettura pienamente legittima che può reggere sistemi complessi per anni, ed è la scelta default consigliata da molti degli architetti software più autorevoli del settore.

Se un giorno un modulo cresce abbastanza da giustificare l'estrazione come microservizio, i confini sono già definiti.

La migrazione è chirurgica invece di essere una riscrittura.

Stai costruendo un sistema che può evolvere verso i microservizi solo dove necessario, senza dover affrontare tutto in una volta.

Microservizi: i costi nascosti che portano la spesa operativa a 2-3 volte quella del monolite

Il costo dei microservizi viene quasi sempre sottostimato. Di solito se ne considerano solo i benefici: scalabilità, indipendenza dei team, resilienza.

Non mostrano mai il conto operativo reale.

Prima di scegliere i microservizi, questi costi vanno messi esplicitamente in bilancio, voce per voce.

Infrastruttura e gestione

I microservizi richiedono Kubernetes, potente ma complesso. Per un team di cinque persone, avere almeno una persona che gestisce il cluster e un costo fisso.

Un cluster minimo adatto alla produzione costa 300–800 € al mese, e comprende due voci principali:

• Control plane: il "cervello" del cluster. Costa zero nel piano Free (ma senza garanzie che rimanga sempre disponibile) oppure ~70 €/mese nel piano Standard (con garanzie contrattuali sull'uptime).
• Nodi worker: le macchine che eseguono effettivamente le tue applicazioni. Sono la parte più costosa e quella che fa variare il totale.

Osservabilita e distributed tracing

In un monolite, un file di log e un debugger bastano.

In un sistema a microservizi, seguire il percorso di una singola richiesta attraverso cinque servizi diversi richiede strumenti dedicati, la capacità di correlare i log tra servizi separati e metriche specifiche per ognuno di essi.

Service mesh e comunicazione sicura

Molti team finiscono per adottare un livello infrastrutturale aggiuntivo che gestisce automaticamente la comunicazione sicura tra servizi, la distribuzione del traffico e la gestione dei guasti.

Questi strumenti sono potenti, ma hanno una curva di apprendimento significativa e rendono i deployment più complessi.

Testing di integrazione e contract testing

Diventa necessario testare che i servizi continuino a "parlarsi" correttamente dopo ogni modifica.

Una disciplina di testing che nel monolite semplicemente non esiste.

Gestione delle failure parziali

In un sistema distribuito, un servizio può rallentare o smettere di rispondere senza che il resto del sistema se ne accorga subito.

Gestire questi guasti parziali richiede strategie specifiche per evitare che il problema si propaghi a cascata, una complessità che nel monolite semplicemente non esiste.

Studi empirici indicano che il costo operativo di un sistema a microservizi è in genere da due a tre volte quello di un monolite equivalente.

Se il tuo progetto non ha i segnali che giustificano questo costo aggiuntivo, stai pagando un prezzo altissimo per complessità che non ti serve.

Ti hanno convinto che la complessità sia un segno di maturità tecnica, ma è esattamente il contrario.

Come migrare da monolite a microservizi: il pattern Strangler Fig passo per passo

Se sei nella situazione in cui hai un monolite esistente e hai i segnali concreti che giustificano l'estrazione di microservizi, il pattern Strangler Fig e il modo piu sicuro per farlo senza riscrivere il sistema dall'inizio e senza fermare il business.

Il nome viene da un tipo di fico tropicale, che cresce avvolgendo un albero ospite, lentamente sostituendo la struttura dell'albero originale.

Il pattern software funziona in modo analogo: nuovi servizi crescono intorno al monolite, intercettando traffico, finché il monolite originale non e stato gradualmente rimpiazzato nelle aree dove ha senso.

Come funziona il pattern Strangler Fig

• Identifica il bounded context da estrarre: quello con i segnali più forti (scalabilità diversa, conflitti di merge, requisiti di compliance).
• Costruisci il nuovo servizio parallelamente al monolite, con il proprio database, infrastruttura e pipeline CI/CD.
• Inserisci un proxy davanti al sistema per smistare il traffico. In ambito .NET, YARP (Yet Another Reverse Proxy, sviluppato da Microsoft) è l'opzione più naturale.
• Migra il traffico progressivamente: inizia con l'1–5%, monitora, aumenta gradualmente.

Rimuovi il codice dal monolite solo quando il nuovo servizio ha gestito il 100% del traffico per almeno quattro settimane.

Questo pattern funziona bene solo se il monolite ha confini sufficientemente chiari per identificare cosa estrarre.

Se e una ”big ball of mud” (software cresciuto senza una struttura chiara) dove tutto dipende da tutto, la migrazione e quasi impossibile senza una fase preliminare di refactoring interno.

Investire in un Modular Monolith fin dall'inizio ha un valore strategico che emerge chiaramente solo anni dopo.

API gateway, service discovery e service mesh: cosa sono e quando servono nei microservizi

Uno degli aspetti più sottovalutati dei microservizi e l'infrastruttura necessaria per farli funzionare correttamente in produzione.

Ogni componente risolve problemi reali, ma richiede competenze specifiche che un team medio italiano spesso non ha.

API Gateway

L'API Gateway è il punto di ingresso unico del sistema: riceve tutte le richieste esterne e si occupa di smistarle, verificare chi le fa, limitare gli abusi e trasformare i dati se necessario.

In ambito .NET e Azure le opzioni più comuni sono Azure API Management, Ocelot (open source .NET) e YARP.

Service Discovery

Il Service Discovery è il meccanismo con cui i servizi si trovano a vicenda automaticamente.

Quando un servizio si avvia, si registra in un elenco centrale così gli altri sanno dove trovarlo senza configurazioni manuali.

Quando un altro servizio deve comunicarci, risolve l'indirizzo attuale attraverso l’elenco centrale.

Service Mesh

Un Service Mesh gestisce tutta la comunicazione tra servizi: la cifra automaticamente, distribuisce il traffico tra le istanze, gestisce i guasti e tiene traccia di cosa succede.

Aggiunge complessità, ma sposta la responsabilità della resilienza dall'applicazione all'infrastruttura.

Ecco i tre componenti a confronto su quello che conta davvero prima di adottarli:

La domanda da farsi è: il tuo team ha le competenze per gestire tutto questo?

E hai davvero bisogno di tutto questo per il volume di traffico e la complessità del tuo sistema?

In molti casi la risposta onesta e no.

Il costo di gestirli prima che siano necessari e reale, costante, e non produce nessun valore per il cliente.

Microservizi, esempi reali: quando hanno salvato il progetto e quando lo hanno affondato

I casi studio concreti sono più informativi di qualsiasi principio astratto.

Questi due scenari ripropongono pattern che si ripetono frequentemente nel mercato italiano, con nomi e dettagli modificati per la riservatezza.

Caso 1: la piattaforma e-commerce che aveva bisogno dei microservizi

Una piattaforma di e-commerce italiana di fascia media ha raggiunto un punto critico: il team di sviluppo era cresciuto a 25 persone, divise in quattro team funzionali.

Il monolite era diventato un collo di bottiglia organizzativo: ogni release richiedeva coordinamento tra tutti i team, i conflitti di merge erano frequenti, e il checkout in periodi di picco doveva reggere 50x il traffico normale.

La decisione di estrarre prima il servizio di checkout, poi il motore di ricerca del catalogo, ha permesso a queste funzionalità di scalare indipendentemente.

Il resto del sistema e rimasto come Modular Monolith.

Questo e l'approccio corretto.

Caso 2: la software house che ha perso 18 mesi sull'architettura sbagliata

Una software house italiana ha convinto un cliente a riscrivere il gestionale legacy come sistema a microservizi.

Il team era di sei sviluppatori, nessuno con esperienza precedente con Kubernetes.

Dopo 18 mesi, il sistema era in produzione ma con problemi gravi: latenza elevata, problemi di consistenza dei dati, e un costo operativo su Azure quattro volte il budget previsto.

La risoluzione e stata una parziale consolidazione in un Modular Monolith.

Un Modular Monolith dall'inizio avrebbe risolto gli stessi problemi senza i costi che hanno quasi affondato il progetto.

Diciotto mesi di un team da sei sviluppatori, a 40.000 euro l'anno ciascuno, su un'architettura che andava rifatta: sono 360.000 euro lordi di lavoro che non hanno prodotto ciò che avrebbero dovuto.

Qualcuno ha pagato quel conto. Di solito il cliente, finché regge.

Poi il margine, finché c'è.

Poi il progetto.

Microservizi o monolite: tre domande concrete per scegliere quella giusta

Un framework decisionale pratico si basa su tre domande chiave da rispondere onestamente basandosi sulla situazione attuale del progetto, non su scenari ipotetici futuri. Potremmo aver bisogno di scalare in futuro non e una risposta valida a nessuna di queste domande.

Domanda 1: quanti team devono rilasciare indipendentemente?

Questa è la domanda più importante.

Se hai un singolo team o team che lavorano in modo coordinato, il monolite o il Modular Monolith è la scelta quasi sempre corretta.

Se hai tre o più team che devono poter rilasciare autonomamente senza aspettarsi a vicenda, i microservizi iniziano ad avere senso organizzativo.

Domanda 2: hai componenti con requisiti di scalabilita davvero diversi oggi?

Il segnale valido è: il componente X ha requisiti di risorse dieci volte superiori agli altri, e questo sta causando sprechi economici o problemi di performance.

In quel caso ha senso estrarlo come servizio autonomo.

Solo quel componente, non l'intero sistema.

Domanda 3: il team ha le competenze per gestire sistemi distribuiti?

Questa domanda va posta onestamente.

Gestire Kubernetes in produzione, implementare gli strumenti necessari per seguire il percorso di una richiesta attraverso tutti i servizi del sistema, progettare il fallimento parziale, gestire la consistenza eventuale: queste sono competenze specifiche.

Se il team non le ha, il costo di apprenderle nel contesto di un sistema in produzione e alto e rischioso.

Se rispondi no alle prime due domande, parti con il Modular Monolith.

Se rispondi no alla terza, parti con il Modular Monolith indipendentemente da quanto rispondi alle prime due.

Nel mercato italiano, la maggior parte delle software house lavora su progetti dove il team non supera i dieci sviluppatori e i domini sono relativamente transazionali.

In questo contesto, il Modular Monolith e quasi sempre la scelta corretta.

Modular Monolith in .NET: implementazione con ASP.NET Core, Clean Architecture e confini espliciti

Il Modular Monolith viene spesso presentato come concetto, raramente come implementazione concreta.

In una solution .NET, la struttura usa progetti separati per ogni modulo, seguendo i principi della Clean Architecture.

Ogni modulo ha tre progetti: il core con le entità di dominio e le interfacce, l'infrastruttura con le implementazioni concrete (EF Core, repository, client HTTP), e i contratti pubblici che espongono solo le interfacce accessibili agli altri moduli.

Ogni modulo espone all'esterno solo il progetto Contracts. Gli altri moduli possono dipendere da quello, ma non dalle sue implementazioni interne.

Questo confine e la differenza tra un Modular Monolith e un monolite tradizionale dove tutto dipende da tutto.

Quando questo confine viene rispettato con disciplina, la struttura diventa la mappa esatta per un'eventuale migrazione a microservizi.

Migrazione dal monolite ai microservizi: database split, timeline realistica e costi nascosti

Il pattern Strangler Fig descrive la strategia a livello alto.

Ma come si traduce in pratica per un team italiano di cinque-dieci sviluppatori?

La risposta onesta e che la migrazione richiede molto più tempo di quanto venga comunicato alle conferenze, e il database split e di gran lunga la parte più difficile.

Perché la migrazione big-bang non funziona

La migrazione big-bang è quella in cui si ferma lo sviluppo di nuove funzionalità, si riscrive il sistema da zero come microservizi, e si fa un cutover (momento in cui si passa definitivamente dal vecchio sistema al nuovo).

In pratica, il sistema vecchio continua ad acquisire nuove funzionalità durante la riscrittura, i requisiti cambiano, e al momento del cutover la versione riscritta e già indietro rispetto al sistema originale.

Il database split: la parte più difficile

Estrarre il codice di un modulo in un servizio separato è relativamente semplice. Estrarre il database è dove la maggior parte delle migrazioni si inceppa.

Il processo avviene in quattro fasi:

• Elimina i JOIN cross-modulo sostituendoli con due query separate unite in memoria.
• Rimuovi le foreign key cross-modulo.
• Duplica i dati di riferimento con proiezioni locali aggiornate tramite eventi.
• Solo a questo punto estrai fisicamente il database del modulo.

Timeline realistica per un team di 5-10 sviluppatori

Mesi 1-2: preparazione (modularizzazione interna, eliminazione JOIN cross-modulo, setup infrastruttura).

Mesi 3-6: estrazione del primo servizio con rollout (processo graduale di rilascio di una nuova versione) graduale.

Mesi 6-18: estrazione dei servizi successivi a 2-3 mesi ciascuno.

I costi nascosti: tempo per acquisire competenze Kubernetes (3-6 mesi di produttività ridotta), infrastruttura cloud (300-800 euro al mese per il control plane di Kubernetes), pipeline CI/CD aggiuntive.

Per un team italiano di cinque-dieci sviluppatori, la migrazione completa richiede 18-36 mesi e un investimento nell'ordine delle centinaia di migliaia di euro.

Se i segnali ci sono, la migrazione vale l'investimento.

Se i segnali non ci sono, il Modular Monolith e la risposta corretta: ti permette di rimandare la complessità senza accumulare debito tecnico, e di estrarre servizi in futuro solo dove e quando diventa davvero necessario.

Luca, quello del nostro esempio, ha cambiato approccio.

Non ha smontato i microservizi il giorno dopo: avrebbe perso altri sei mesi.

Ha consolidato progressivamente i servizi meno giustificati, ha implementato un Modular Monolith per i nuovi bounded context, e ha tenuto microservizi solo dove i tre segnali c'erano davvero.

I costi operativi sono tornati a un livello sostenibile. Il team lavora su funzionalità invece di gestire infrastruttura.

Non perché ha imparato più tecnologie.

Perché ha smesso di scegliere architetture in base alla moda e ha iniziato a sceglierle in base ai segnali del suo sistema.

La decisione architetturale e quella che, sbagliata, si paga per anni: in complessità accumulata, in costi operativi, in turnover del team che non riesce a lavorare in modo efficiente.

Ogni sprint con un'architettura sbagliata per il tuo contesto e debito operativo che qualcuno, prima o poi, paga.

E quel qualcuno spesso sei tu, nel momento meno opportuno.

Saper leggere questi segnali e tradurli in decisioni architetturali che reggono nel tempo non è una competenza che si acquisisce guardando tutorial.

Si acquisisce lavorando su sistemi reali con qualcuno che ha già fatto quegli errori e sa dove portano.

Il Corso Architetto Software AI è strutturato esattamente per questo.

Luca ha sistemato le cose.

Non subito, non gratis, ma le ha sistemate.

Chi non le sistema di solito non è perché non vuole. È perché crede che il problema sia abbastanza piccolo da gestirsi da solo, o abbastanza lontano da poter aspettare il prossimo progetto.

Ci sono due tipi di sviluppatori che arrivano alla fine di questo articolo.

Il primo chiude la tab.

Ha trovato conferma di quello che già pensava, si sente più informato, torna al lavoro. I

l problema architetturale rimane esattamente dov'era. Anzi, adesso ha anche un nome preciso.

Il secondo si fa una domanda scomoda: se i segnali che ho appena letto stanno descrivendo il mio sistema, cosa sto aspettando che succeda per muovermi?

Non sto dicendo che il tuo progetto stia andando male.

Sto dicendo che ogni decisione architetturale sbagliata si paga due volte: una quando la prendi, e una quando la smontano.

La seconda rata arriva sempre nel momento meno opportuno, con il cliente in attesa e il team già sotto pressione.

Il passaggio da senior ad Architetto Software vale, nel mercato italiano almeno 1.250 euro al mese.

Ogni mese in cui stai gestendo complessità che non dovrebbe esistere è un mese in cui stai pagando il prezzo di un'architettura che non hai ancora imparato a progettare bene.

Se stai pensando "ci penso", sappi che è esattamente quello che si dice il tipo che chiude la tab.

Il Corso Architetto Software AI non lavora su scenari astratti.

Lavora sull'architettura del tuo progetto concreto, con chi ha già fatto quegli errori su sistemi enterprise reali e sa dove portano.

Il tipo di competenza che separa chi subisce le decisioni architetturali da chi le prende.

Potresti aspettare che sia il prossimo progetto a insegnarti la lezione.

Di solito è il metodo più costoso.