TL;DR — preferire il monolite modulare come default
Il dibattito architetturale del 2016–2020 — "i monoliti sono morti, i microservizi sono il futuro" — è stato ampiamente corretto dalla dura esperienza operativa. Ecco la versione breve:
- Monolite modulare come default. Moduli puliti, confini di dominio applicati, una singola pipeline di deployment. Questo è il punto di partenza corretto per la grande maggioranza delle applicazioni web, inclusi SaaS B2B, marketplace e portali enterprise.
- Estrarre i servizi quando si ha una ragione concreta. Profili di scalabilità diversi, cadenze di deployment indipendenti, o confini di proprietà del team che un monolite non può esprimere chiaramente. Non prima.
- I microservizi completi hanno senso su larga scala. Pensate a 20+ ingegneri, 10 milioni+ di richieste al giorno, e SLA di servizio genuinamente divergenti. Al di sotto di quella soglia, l'overhead è una pura tassa sulla velocità del vostro team.
- Un semplice monolite non è vergognoso. Shopify, Stack Overflow e Basecamp hanno generato miliardi di dollari di fatturato con monoliti ben ottimizzati. L'architettura è sbagliata solo se vi impedisce di fare qualcosa che dovete fare.
Le tre opzioni definite
Monolite tradizionale
Una singola applicazione deployabile dove tutta la logica di business, l'accesso ai dati e la presentazione vivono in un'unica codebase e processo. Ogni funzionalità viene consegnata insieme; il database è condiviso; scalare significa eseguire più copie dell'intera applicazione. La classica app Rails, il progetto Django o il servizio Spring Boot è un monolite.
Monolite modulare
Sempre un singolo binario deployabile, ma il codice è partizionato in moduli ben definiti — ognuno con la propria logica di dominio, il proprio namespace dello schema del database e la propria interfaccia pubblica. I moduli comunicano tramite API in-process o contratti di messaggi, non chiamate HTTP. Il risultato è una codebase che si deploya semplicemente ma è strutturata per consentire un'estrazione futura. È l'architettura a cui ci rivolgiamo per prima per i nostri engagements di sviluppo di applicazioni web per i clienti negli USA e in Europa.
Microservizi
Una raccolta di servizi deployabili indipendentemente, ognuno responsabile di un dominio ristretto, che comunicano tramite HTTP o un message broker (Kafka, RabbitMQ, SQS). Ogni servizio ha il proprio database, la propria pipeline CI/CD e il proprio footprint operativo. Fatto bene, permette alle grandi organizzazioni di consegnare velocemente senza interferire tra loro. Fatto prematuramente, è un monolite distribuito con tutti gli svantaggi di entrambi i mondi e nessuno dei vantaggi di nessuno dei due.
Cosa può fare davvero un monolite moderno
Il racconto secondo cui "monolite equivale a legacy" è un artefatto di marketing dell'era Kubernetes. Siamo precisi su cosa i monoliti moderni possono e non possono fare.
Scalano orizzontalmente
Eseguire quattro copie di un'app Rails o Django dietro un load balancer è scalabilità orizzontale. Funziona finché il database non diventa il collo di bottiglia — a quel punto si aggiungono repliche in lettura e connection pooling, non necessariamente un nuovo servizio. Stack Overflow serve miliardi di pagine su nove server on-premise. Il collo di bottiglia non era mai il monolite; era la mancanza di caching, indicizzazione e disciplina delle query.
Supportano l'iterazione rapida
Un monolite ha una sola pipeline di deployment. Un unico insieme di test di integrazione. Un solo posto dove cercare un bug. Per un team di 3–15 ingegneri, questo è un enorme vantaggio di coordinamento. Ogni sistema distribuito che aggiungete moltiplica i modi di guasto che dovete monitorare e gli scenari di rollback che dovete esercitare.
Supportano i confini di conformità
La residenza dei dati GDPR, i log di audit HIPAA e i controlli SOC 2 sono più facili da implementare all'interno di una sola applicazione che da applicare su una rete di servizi. Un singolo audit trail, un singolo secrets store, un singolo punto di terminazione TLS. Vedete i pattern che utilizziamo in come costruire un SaaS multi-tenant — la multi-tenancy è pienamente realizzabile all'interno di un monolite modulare.
Dove i monoliti hanno davvero difficoltà
Ci sono limitazioni reali. Se il vostro servizio di checkout deve gestire 50 volte il traffico del vostro modulo di reporting, scalare l'intera app spreca risorse. Se la vostra pipeline di inferenza ML ha requisiti di runtime completamente diversi (GPU, Python, diversa cadenza di deployment), mantenerla nello stesso processo è scomodo. Queste sono le ragioni giuste per estrarre un servizio — non la moda ingegneristica.
Quando i microservizi sono davvero vantaggiosi
Ci sono scenari in cui i microservizi sono la risposta giusta. Ecco come riconoscerli.
Profili di scalabilità genuinamente diversi
Se il vostro motore di raccomandazione prodotti riceve 1.000 richieste al secondo durante i picchi mentre la vostra API di impostazioni utente ne riceve 5, non ha senso scalarli insieme. Una volta che potete quantificare questa divergenza in produzione — non in una sessione su lavagna — l'estrazione del servizio si ripaga da sola. Correlato: vedete lo stack di agenti IA enterprise 2026 per capire perché i workload intensivi in inferenza spesso giustificano l'isolamento esattamente per questo motivo.
Cadenze di deployment indipendenti
Quando team di prodotto separati devono consegnare più volte al giorno senza coordinamento, una singola pipeline di deployment diventa un collo di bottiglia. Questa è la motivazione originale di Amazon per i microservizi — non le performance, ma la velocità organizzativa. Se il vostro team analytics e il vostro team di fatturazione si aspettano a vicenda che il codice dell'altro sia stabile prima di un rilascio, l'architettura sta creando un problema di coordinamento umano che un confine di servizio risolverebbe.
Domini di guasto isolati
Un bug catastrofico in un monolite fa cadere l'intera applicazione. In un'architettura a microservizi, un bug nel vostro servizio di notifiche non deve necessariamente far cadere il checkout. I circuit breaker, i bulkhead e la degradazione graziosa sono pattern che hanno senso solo quando avete confini di servizio ai quali applicarli. Per i flussi ad alto fatturato — pagamenti, API principale, autenticazione — la garanzia di isolamento vale il costo operativo.
Confini regolatori e di residenza dei dati
Un'azienda americana che serve clienti europei sotto il GDPR potrebbe aver genuinamente bisogno che i dati residenti in Europa siano elaborati in un servizio separatamente deployato e verificato, non solo un flag di configurazione in un'app condivisa. Idem per l'isolamento del perimetro PCI DSS — i dati dei titolari di carte elaborati in un servizio separato con il proprio confine di rete sono architettonicamente più puliti che ridurre la superficie di attacco di un monolite.
Costi, dimensioni del team e onere operativo
I microservizi non sono gratuiti. Ogni servizio che aggiungete moltiplica il costo di infrastruttura e personale. Ecco un bilancio onesto.
Costo dell'infrastruttura
Ogni servizio ha bisogno del proprio: compute (container, Lambda o VM), database o namespace del database, integrazione del gestore di segreti, regola di routing del load balancer o dell'API gateway, voce della pipeline di aggregazione dei log, e monitor di health check. Per un'architettura a dieci servizi, ne gestite dieci di ognuno. Su AWS o GCP, un monolite modulare spesso costa il 60–80% in meno di infrastruttura mensile rispetto a un equivalente mesh di microservizi che gestisce lo stesso traffico.
Costo dell'observability
Un monolite fallisce con uno stack trace in un unico flusso di log. Un sistema distribuito fallisce con trace parziali distribuite su cinque servizi, due code asincrone e uno strato di caching. Il tracing distribuito (Jaeger, Tempo, AWS X-Ray), l'aggregazione di log strutturati (Loki, Datadog, CloudWatch) e i dashboard di salute dei servizi sono obbligatori, non opzionali. Preventivate un ingegnere di piattaforma dedicato più 2.000–8.000 USD/mese in tool SaaS per un team che gestisce 10+ servizi.
Requisiti di dimensione del team
La regola delle due pizze di Amazon (6–10 ingegneri per servizio) è il minimo operativo affinché ogni servizio sia mantenuto senza continui cambi di contesto. Al di sotto di 20–30 ingegneri in totale, i microservizi significano che ogni ingegnere possiede più servizi — esattamente l'overhead di coordinamento che l'architettura avrebbe dovuto eliminare. Vedete anche il playbook di riduzione del churn SaaS per capire come le decisioni architetturali a monte influenzano l'affidabilità del prodotto che guida la retention.
| Dimensione | Monolite | Monolite modulare | Microservizi |
|---|---|---|---|
| Complessità di deployment | Bassa | Bassa | Alta |
| Costo infrastruttura (stesso traffico) | Il più basso | Il più basso | 2–5x più alto |
| Overhead di observability | Minimo | Minimo | Significativo |
| Scalabilità orizzontale | A grana grossa | A grana grossa | A grana fine |
| Deployment indipendenti per team | No | Parziale | Sì |
| Team min. per funzionare bene | 3–5 ingegneri | 5–15 ingegneri | 20+ ingegneri |
| Tempo al primo deployment in produzione | 1–2 settimane | 1–3 settimane | 4–8 settimane |
Scalare correttamente un'applicazione web
Prima di scegliere un'architettura basata su una scala futura che non avete ancora, applicate questi leve di scalabilità in ordine — la maggior parte delle applicazioni non ha mai bisogno di andare oltre il passo tre.
1. Scalabilità verticale e ottimizzazione delle query
Raddoppiate la dimensione della vostra istanza di database. Aggiungete un indice alla query lenta. Abilitate il connection pooling (PgBouncer, RDS Proxy). Questa è ingegneria gratuita o quasi gratuita che comunemente acquista 5–10x di margine di capacità. La maggior parte delle applicazioni che "hanno bisogno di microservizi per la scala" ha in realtà bisogno di un indice di database e di una cache Redis.
2. Scalabilità orizzontale dell'applicazione
Eseguite più istanze del vostro monolite dietro un load balancer. Aggiungete repliche in lettura per i workload intensivi in lettura. Usate una CDN per scaricare gli asset statici e le risposte API in cache. Un singolo processo Rails o Node.js a 4 vCPU gestisce ~500 richieste/secondo. Otto istanze dietro un load balancer ne gestiscono 4.000. Raggiungete questo limite lentamente.
3. Caching e accodamento asincrono
Redis o Memcached davanti ai vostri percorsi di lettura caldi. Una coda di job in background (Sidekiq, Celery, Bull) per tutto ciò che non deve essere sincrono — email, webhook, generazione di report, chiamate API di terze parti. Scaricare il lavoro asincrono elimina una classe di latenza di coda di richiesta lenta che rende terribile il vostro p95 senza alcun cambiamento architetturale reale.
4. Estrarre un servizio alla volta
Quando un percorso caldo specifico è genuinamente un collo di bottiglia e i passi precedenti sono esauriti, estraete quel servizio usando il pattern strangler fig. Instradate il nuovo traffico verso il servizio mentre il monolite gestisce il resto. Migrate in modo incrementale. Non tentate una riscrittura big bang dal monolite ai microservizi — il tasso di fallimento è alto e il costo è enorme.
Matrice decisionale
Usate questa matrice quando fate la scelta architettuale. Valutate ogni riga per la vostra situazione attuale — non per l'azienda che aspirate ad essere tra tre anni.
| Criterio | Scegliere il monolite modulare se… | Considerare i microservizi se… |
|---|---|---|
| Dimensione del team | Meno di 20 ingegneri | 20+ ingegneri su più squad di prodotto |
| Pattern di traffico | Uniforme o basso volume oggi | Carichi di picco misurati e divergenti per dominio |
| Cadenza di deployment | Uno o due team, rilasci coordinati | Più team, cadenze indipendenti richieste |
| Isolamento di conformità | GDPR/SOC 2 standard gestibile in un'app | Perimetro PCI DSS titolari di carte o residenza dati rigorosa |
| Maturità DevOps | Nessun ingegnere di piattaforma dedicato | Team Platform/SRE già in place |
| Mix tecnologico | Un linguaggio/runtime principale | Genuino bisogno di runtime misti (es. servizio ML GPU) |
| Requisito di tolleranza ai guasti | Downtime totale accettabile per incidenti rari | Degradazione parziale richiesta (il checkout deve sopravvivere a un'interruzione dell'analytics) |
FAQ
Una start-up dovrebbe usare i microservizi?
Quasi mai all'inizio. I microservizi moltiplicano la superficie operativa — service discovery, tracing distribuito, pipeline CI/CD indipendenti e un team abbastanza grande da gestire ogni servizio. Il vincolo di una start-up è la consegna rapida del prodotto e l'apprendimento veloce, non la flessibilità dell'infrastruttura. Iniziate con un monolite modulare; estraete i servizi quando un confine concreto di scalabilità o di proprietà ve lo impone.
Cos'è un monolite modulare?
Un monolite modulare è una singola applicazione deployabile, divisa internamente in moduli ben definiti e debolmente accoppiati — ognuno con la propria logica di dominio, il namespace dello schema del database e la superficie API pubblica. Viene deployato come un singolo processo ma è strutturato in modo che i moduli individuali possano essere estratti in servizi separati in seguito con un refactoring minimo. È il punto di equilibrio ideale per la maggior parte dei team con meno di 50 ingegneri.
Quando i microservizi sono vantaggiosi?
I microservizi sono vantaggiosi quando: (1) diverse parti del sistema hanno profili di scalabilità genuinamente diversi — il checkout gestisce 10 volte il carico dell'admin; (2) team indipendenti devono deployare senza coordinare i rilasci; (3) un servizio specifico richiede un technology stack, un SLA o un confine di conformità diverso. Se nessuna di queste condizioni è vera oggi, l'overhead dei microservizi è puro costo.
I microservizi sono più scalabili di un monolite?
Non automaticamente. Un monolite ben ottimizzato su un'infrastruttura cloud moderna gestisce milioni di richieste al giorno con scalabilità orizzontale, connection pooling e repliche in lettura. I microservizi consentono una scalabilità granulare dei percorsi caldi — ma questo vantaggio si materializza solo quando i diversi servizi hanno genuinamente forme di traffico diverse. Molti team aggiungono la complessità dei microservizi prima di avere il traffico che la giustificherebbe.
Quanto dovrebbe essere grande il team per gestire i microservizi?
La regola delle due pizze di Amazon è una guida utile: ogni servizio dovrebbe essere gestibile da un team di 6–10 ingegneri. In pratica avete bisogno di almeno un ingegnere DevOps o di piattaforma dedicato, copertura SRE, strumenti di observability e abbastanza sviluppatori per mantenere ogni servizio senza continui cambi di contesto. Al di sotto di 20–30 ingegneri in totale, i microservizi di solito creano più overhead di coordinamento di quanti ne eliminano.
Posso migrare da un monolite a microservizi in seguito?
Sì — e questo è il percorso raccomandato. Costruite un monolite modulare con confini di dominio puliti fin dall'inizio, e l'estrazione di un servizio in seguito è uno sforzo contenuto: spostate il codice di un modulo, dividete le sue tabelle del database e aggiungete un contratto API. Il pattern strangler fig — che instrada il traffico in modo incrementale verso un nuovo servizio mentre il monolite gestisce il resto — è collaudato per questa migrazione. Non progettate per i microservizi dal primo giorno a meno che non abbiate già il team e il traffico che lo richiedono.
Ultimo aggiornamento 4 giugno 2026. Le raccomandazioni architetturali si basano su engagement in produzione consegnati per clienti americani ed europei tra il 2022 e il 2026. Le cifre sui costi sono stime; la spesa effettiva per l'infrastruttura varia in base al cloud provider, alla regione e alla forma del traffico.
