Microservices vs monolith 2021: guida architetturale per PMI

Nel 2010 Netflix completa la migrazione dal data center monolitico ad AWS adottando un’architettura a centinaia di servizi indipendenti. Da quel momento, il termine “microservizi” passa da curiosità di laboratorio a feticcio architetturale per tutta l’industria del software. Nel 2014 James Lewis e Martin Fowler pubblicano l’articolo che diventerà la pietra miliare del movimento; nel 2015 Sam Newman firma la prima edizione di Building Microservices, oggi giunta alla seconda edizione (2021).

Il problema arriva poco dopo: tra il 2017 e il 2021 si diffonde nelle PMI italiane un fenomeno che gli architetti software più navigati chiamano “microservices envy”. Startup con quindici sviluppatori, team SaaS B2B con un solo prodotto, software house con cinque clienti enterprise iniziano a spezzare in trenta servizi indipendenti applicazioni che fino al giorno prima funzionavano bene da monolite. Il risultato è quasi sempre lo stesso: pipeline CI/CD ingestibili, latenze raddoppiate, debugging impossibile, conti AWS triplicati e nessun beneficio reale per il business.

La contro-narrazione nasce ufficialmente nel 2015 con il post MonolithFirst di Martin Fowler, prosegue nel 2020 con DHH di Basecamp che racconta la “majestic monolith” dietro a HEY, e culmina nel 2021 con il blog post di Shopify sul refactor del proprio monolite Ruby on Rails verso un modular monolith da oltre 2,8 milioni di righe di codice. La domanda per i CTO delle PMI italiane non è più “quando passiamo ai microservizi” ma “ci serve davvero passare ai microservizi”. Questa guida prova a rispondere senza ideologie.

Cosa è un monolite (e perché non è una parolaccia)

Un monolite è un’applicazione in cui tutta la business logic, l’interfaccia utente e l’accesso ai dati sono impacchettati in un singolo deployable unit: un file WAR Java, una Rails app, un eseguibile .NET, un container Docker. Non significa “codice scritto male”: significa “codice che si rilascia tutto insieme”.

Nel 2021 i monoliti più famosi del mondo movimentano una fetta enorme dell’economia digitale globale:

• Shopify: Ruby on Rails, oltre 2,8 milioni di righe, gestisce il Black Friday di 1,7 milioni di merchant senza microservizi (in refactor modulare dal 2020).
• GitHub: ancora oggi una Rails monolitica al cuore della piattaforma, con servizi periferici (Actions, Codespaces) come satelliti.
• Basecamp e HEY: David Heinemeier Hansson racconta apertamente nel 2020 la “majestic monolith” Rails che fa girare il loro intero business.
• Stack Overflow: cluster di nove server fisici, .NET monolitico, gestisce miliardi di pagine viste l’anno con un team di una dozzina di developer.

Il messaggio non è “tornate al monolite per nostalgia”: è “il monolite, fatto bene, scala molto più di quanto la moda vi racconti”.

Cosa sono i microservizi secondo Sam Newman

La definizione canonica di Sam Newman in Building Microservices (2° edizione, 2021) recita: “I microservizi sono servizi rilasciabili in modo indipendente, modellati attorno a un dominio di business”. I quattro pilastri sono:

1. Indipendenza di deploy: ogni servizio si rilascia senza coordinarsi con gli altri.
2. Boundary di dominio: i confini dei servizi seguono i bounded context del Domain Driven Design di Eric Evans.
3. Database privato: ogni servizio ha il proprio database (anti-pattern: shared database).
4. Comunicazione via rete: HTTP/REST, gRPC, messaggi asincroni via Kafka o RabbitMQ.

Newman insiste su un punto che nel 2021 viene ignorato dal 90% delle PMI che si avvicinano all’argomento: i microservizi sono una scelta organizzativa prima che tecnica. Se la vostra organizzazione non è pronta a gestire team autonomi cross-funzionali con piena ownership del ciclo di vita di un servizio (sviluppo, deploy, monitoraggio, on-call), spezzare il codice in venti servizi non risolve nulla: sposta solo i problemi di accoppiamento dal compilatore alla rete.

Il modular monolith come terza via

Il modular monolith è il termine che dal 2019 in poi si afferma per descrivere un’architettura che cerca il meglio dei due mondi: un singolo deployable, ma con confini interni espliciti tra moduli. Shopify è il caso più documentato: Kirk Kuykendall nel 2019 racconta come la software house canadese stia riorganizzando il proprio monolite Rails in pacchetti con dipendenze esplicite, sfruttando strumenti come Packwerk (open source da Shopify, 2020).

I vantaggi rispetto al monolite tradizionale:

• Confini di dominio chiari e violazioni rilevate a build time.
• Refactoring incrementale possibile, anche verso microservizi futuri.
• Riduzione del “big ball of mud” tipico dei monoliti vecchi.

I vantaggi rispetto ai microservizi:

• Una sola pipeline di deploy.
• Nessuna latenza di rete tra moduli.
• Transazioni ACID locali senza saghe distribuite.
• Debugging con stack trace completi.

Per una PMI italiana con un team tra 10 e 30 sviluppatori, il modular monolith nel 2021 è la scelta architetturale di default consigliata. Si parte da qui, e si valuta il passaggio a microservizi solo se la pressione organizzativa lo richiede.

Conway’s law e topologie di team

Nel 1968 Melvin Conway scrive una frase che il mondo del software ha impiegato cinquant’anni a prendere sul serio: “Le organizzazioni che progettano sistemi sono vincolate a produrre design che sono copia delle loro strutture comunicative”. È la legge di Conway: l’architettura del vostro software riflette inevitabilmente la struttura della vostra organizzazione.

Nel 2019 Matthew Skelton e Manuel Pais pubblicano Team Topologies, libro che diventa il riferimento per chi progetta organizzazioni software-intensive nel 2020-2021. Identificano quattro tipologie di team:

1. Stream-aligned team: team con ownership end-to-end di un flusso di valore (es. team Pagamenti, team Onboarding).
2. Enabling team: team di esperti che aiutano altri team a costruire capability (es. team Sicurezza che insegna OWASP ai team prodotto).
3. Complicated-subsystem team: team dedicati a sottosistemi complessi (es. motore di pricing, motore di matching algoritmico).
4. Platform team: team che fornisce una piattaforma interna self-service (CI/CD, monitoring, deploy).

L’architettura a microservizi presuppone una struttura organizzativa fatta di molti stream-aligned team con autonomia operativa. Se la vostra PMI ha un singolo team di sviluppo prodotto di dodici persone, costruire venti microservizi significa creare venti repository che lo stesso team dovrà gestire: il “reverse Conway maneuver” non funzionerà, perché non c’è reverse da fare.

Quando preferire un monolite

Le condizioni in cui un monolite (anche modulare) è quasi sempre la scelta migliore nel 2021:

• Team sotto i 30 sviluppatori totali. Sotto questa soglia, il coordinamento umano costa meno del coordinamento tra servizi.
• Prodotto in fase pre product-market fit. Quando il dominio è ancora in scoperta, ogni boundary di servizio è un’ipotesi che cambierà settimana prossima: la rigidità dei boundary di rete è un costo enorme.
• Dominio di business non chiaro. I confini dei servizi devono seguire bounded context del dominio (DDD), e se il dominio non è chiaro i confini saranno sbagliati.
• Team senza DevOps maturi. Microservizi senza una pratica matura di Docker, Kubernetes, osservabilità distribuita, CI/CD avanzata producono solo dolore.
• Budget infrastrutturale limitato. Su AWS un monolite ben dimensionato costa frazioni di un’architettura a microservizi equivalente in carico utente.
• Vincoli di latenza stretti. Ogni chiamata di rete aggiunge 1-10 ms: con 20 chiamate per request, il monolite resta competitivo.

Una PMI italiana SaaS B2B con 50.000 utenti, ARR di 3 milioni, team di 15 sviluppatori, nel 2021 dovrebbe lavorare al 99% su un monolite modulare ben fatto, non su un’architettura a microservizi.

Quando preferire microservizi

I microservizi diventano una scelta sensata quando si verificano contemporaneamente più condizioni:

• Team complessivo sopra le 50 persone, organizzate in più squad indipendenti.
• Esistono parti del sistema con cicli di rilascio molto diversi (es. core stabile da rilasciare ogni 2 settimane vs frontend che cambia ogni giorno).
• Esistono parti del sistema con vincoli di scala radicalmente diversi (es. un servizio che gestisce 1 req/sec e uno che ne gestisce 10.000/sec).
• Esistono parti del sistema scritte in tecnologie diverse e ha senso mantenerle separate (es. un motore ML in Python e un’app transazionale in Go).
• L’organizzazione è distribuita geograficamente, con team su fusi orari diversi che fanno fatica a sincronizzarsi su un singolo codebase.
• Esiste già una piattaforma interna di developer experience: pipeline standardizzate, monitoring centralizzato, runbook condivisi.

Anche in questi casi la raccomandazione di Sam Newman resta: iniziare da pochi servizi grandi, non da quaranta servizi piccoli. La granularità si raffina nel tempo, mai a priori.

Il pattern Strangler Fig per la migrazione

Quando una PMI decide razionalmente di migrare da monolite a microservizi, il pattern di riferimento è lo Strangler Fig, descritto da Martin Fowler in un articolo del 2004 e diventato lo standard de facto per le migrazioni di sistema dal 2010 in poi.

La metafora viene dalla pianta del fico strangolatore, che si avvolge attorno a un albero ospite e gradualmente lo sostituisce. Applicata al software:

1. Si pone un proxy davanti al monolite. Può essere un API gateway (Kong, Tyk) o un reverse proxy nginx/Envoy.
2. Si estrae un singolo bounded context in un nuovo servizio.
3. Si configura il proxy per dirigere le chiamate a quel context verso il nuovo servizio invece che al monolite.
4. Si rimuove la funzionalità dal monolite solo dopo che il nuovo servizio è stabile in produzione.
5. Si ripete per il prossimo bounded context.

L’errore tipico delle PMI italiane è il “big bang rewrite”: riscrivere tutto da zero in microservizi mentre il monolite continua a essere mantenuto. Joel Spolsky ha scritto contro questo approccio nel 2000 (Things You Should Never Do, Part I): vent’anni dopo, è ancora l’errore più comune e costoso che si possa fare.

Tecnologie 2021: l’ecosistema che dovete conoscere

Nel 2021 lo stack tecnologico per microservizi è maturo, ma proprio per questo è vasto. Mappa essenziale:

Container e orchestrazione

• Docker (1.0 nel 2014, mainstream dal 2016): standard de facto per packaging.
• Kubernetes (1.0 nel 2015, donato a CNCF, oggi 1.22): standard de facto per orchestrazione.
• Helm: package manager per Kubernetes, indispensabile in produzione.
• k3s, k0s: distribuzioni Kubernetes leggere per edge ed esperimenti.

Service mesh

• Istio (1.0 nel 2018, 1.10 nel 2021): il più completo, anche il più complesso da operare.
• Linkerd (2.10 nel 2021): più leggero, scritto in Rust per il data plane.
• Consul Connect (1.6 nel 2019): la proposta di HashiCorp, integrata con il loro stack.
• Envoy: il proxy sidecar L7 standard, sviluppato da Lyft, donato a CNCF nel 2017.

Messaging e streaming

• Apache Kafka (2.8 nel 2021): streaming distribuito ad alta velocità.
• RabbitMQ: message broker AMQP, ottimo per code di lavoro.
• NATS: messaging ultraleggero, da CNCF.

Comunicazione sincrona

• gRPC: RPC binario su HTTP/2, contratti Protobuf, performante.
• REST: ancora la lingua franca per API esterne.
• GraphQL: utile come BFF (Backend For Frontend), meno come comunicazione interna.

Database: shared DB anti-pattern, CQRS ed Event Sourcing

Il primo errore di chi migra a microservizi nel 2021 è mantenere un database condiviso tra più servizi. È l’anti-pattern documentato più tossico: il database diventa un punto di accoppiamento implicito tra servizi che credevano di essere indipendenti, e qualunque modifica di schema diventa un’operazione di coordinamento tra team.

La regola d’oro è un database per servizio. Implica scegliere consapevolmente:

• Postgres per servizi transazionali con vincoli ACID forti.
• MongoDB per servizi document-oriented (cataloghi, profili utente flessibili).
• Redis per cache, code, dati effimeri.
• Elasticsearch per ricerca full-text.
• ClickHouse per analytics OLAP.

Due pattern avanzati che entrano in gioco quando si scala:

CQRS (Command Query Responsibility Segregation), formalizzato da Greg Young nel 2010, separa il modello di scrittura da quello di lettura. Le scritture vanno su un modello normalizzato; le letture su modelli denormalizzati ottimizzati per query specifiche. Utile quando il rapporto letture/scritture è molto sbilanciato (es. e-commerce, social).

Event Sourcing, descritto da Greg Young nel 2006 e da Martin Fowler negli stessi anni, registra lo stato del sistema come sequenza immutabile di eventi invece che come snapshot del current state. Lo stato corrente si deriva replicando gli eventi. Estremamente utile per audit, time-travel debugging, compliance — ma anche estremamente costoso in complessità di sviluppo. Da introdurre solo quando il dominio lo richiede davvero (finance, healthcare, supply chain), non per moda.

Observability: distributed tracing e service mesh metrics

In un monolite, quando qualcosa va storto, basta uno stack trace per capire dove e perché. In un sistema a microservizi, una singola richiesta utente attraversa 10-30 servizi: lo stack trace di un singolo servizio è inutile. Serve distributed tracing.

Gli strumenti di riferimento nel 2021:

• OpenTelemetry: progetto CNCF (incubating dal 2021) nato dalla fusione di OpenTracing e OpenCensus. Standard de facto per strumentare codice.
• Jaeger: backend di tracing donato da Uber a CNCF, graduated 2019.
• Zipkin: il pioniere, sviluppato da Twitter.
• Prometheus: time-series database per metriche, standard CNCF.
• Grafana: dashboard per metriche, log, trace.
• Loki: log aggregator di Grafana Labs, integrato con Prometheus.
• Elastic APM: alternativa commerciale con Kibana.

Un sistema a microservizi senza distributed tracing non è un sistema a microservizi: è una bomba a orologeria. La regola operativa: se non potete spiegare in 5 minuti perché una specifica richiesta utente delle 14:32 ha impiegato 4 secondi invece di 200 ms, non siete pronti per i microservizi.

API gateway: il fronte verso il mondo

Un’architettura a microservizi non espone i singoli servizi al mondo esterno: davanti si mette un API gateway che fa autenticazione, rate limiting, caching, routing, trasformazione di payload.

Le opzioni mature nel 2021:

• Kong (2.x): open source, basato su nginx + OpenResty, plugin marketplace ampio.
• Tyk: scritto in Go, focus su API management completo, versione open source disponibile.
• Ambassador (acquisita da Datawire e poi Solo.io): basato su Envoy, nativo Kubernetes.
• AWS API Gateway: managed AWS, ottimo se siete dentro l’ecosistema AWS, costoso se il traffico cresce molto.
• Azure API Management: l’equivalente Microsoft, integrato con AD e con il resto dello stack.
• Apigee (Google): la soluzione enterprise più matura, costo importante.

Un errore comune è mettere logica di business nell’API gateway: deve restare un componente di infrastruttura, non un secondo backend. Pattern correlato: il BFF (Backend For Frontend), descritto da Phil Calcado di SoundCloud nel 2015, dove ogni client (web, mobile iOS, mobile Android) ha un proprio backend dedicato che orchestra le chiamate ai microservizi.

Errori comuni che le PMI italiane fanno nel 2021

Dopo cinque anni di consulenze su architetture distribuite, l’elenco degli errori ricorrenti è consolidato:

1. Microservizi senza DevOps maturi. Il team continua a fare deploy manuali, niente pipeline CI/CD per ogni servizio, niente observability. Il risultato: vent’anni di latenza operativa concentrati in sei mesi.
2. Distributed monolith. Servizi separati ma così accoppiati che si deve rilasciarli tutti insieme: il peggio dei due mondi. Sintomi: ogni feature tocca 5 servizi; nessun servizio si rilascia da solo.
3. Eventual consistency ignorata. Si progetta come se i dati fossero ACID, poi in produzione il customer service riceve chiamate perché “il sistema dice una cosa e la dashboard ne dice un’altra”. Pattern correlato: Saga per transazioni distribuite.
4. Nessun canary deploy. Si rilascia tutto in produzione contemporaneamente. Quando un servizio rompe, rompe per il 100% del traffico. Servono blue-green deployment, canary, feature flags.
5. Boundary di servizio sbagliati. Servizi divisi per layer tecnico (servizio “database”, servizio “API”, servizio “frontend”) invece che per dominio. Risultato: ogni feature di business tocca tutti i servizi.
6. Ignorare i pattern di resilienza. Niente Circuit Breaker (Michael Nygard, 2007), niente Bulkhead, niente retry con exponential backoff. Un servizio lento o giù tira giù tutta la catena.
7. Sicurezza come ripensamento. Comunicazione interna in chiaro, niente mTLS, secret management improvvisato. Il service mesh nasce anche per risolvere questo, ma serve usarlo.
8. Database condiviso. L’anti-pattern numero uno, già trattato sopra.

Caso reale: PMI italiana SaaS B2B che decide di NON migrare

Nel 2021 una PMI italiana B2B che produce un SaaS verticale per il settore manifatturiero ci chiede una consulenza sull’opportunità di migrare il proprio monolite Django + Postgres verso un’architettura a microservizi. I numeri di partenza:

• Monolite Django da 5 anni, 280.000 righe di codice Python.
• Postgres single-master con replica di lettura, 380 GB di dati.
• Team di sviluppo: 18 sviluppatori, distribuiti in 3 squad (core, integrations, frontend).
• 1.200 aziende clienti, ARR di 4,8 milioni di euro, crescita 35% anno su anno.
• Deploy frequency: 2-3 volte a settimana.
• Incident di produzione critici: meno di 1 al trimestre.
• Tempo medio di onboarding di un nuovo developer: 2 settimane per essere produttivo.

Dopo tre settimane di analisi, la raccomandazione è stata non migrare. Le ragioni:

1. La pressione organizzativa non c’era. 18 sviluppatori in 3 squad si coordinano benissimo su un monolite ben fatto.
2. Il dominio era stabile ma in continua evoluzione marginale: spostare i boundary in rete avrebbe rallentato l’evoluzione.
3. Le performance del monolite erano largamente sufficienti per il carico attuale e per i prossimi 3 anni di crescita prevista.
4. La cultura DevOps non era ancora matura: due ingegneri di piattaforma a tempo parziale gestivano l’infrastruttura. Migrare a Kubernetes + Istio avrebbe richiesto un team dedicato che l’azienda non poteva permettersi.
5. Il costo opportunity sarebbe stato enorme: 6-9 mesi di team a investire in migrazione senza produrre feature visibili al mercato in pieno momento di crescita.

La soluzione adottata è stata diversa: refactor verso un monolite modulare con pacchetti Python ben definiti, isolamento di alcuni domini critici (fatturazione, pagamenti) in moduli con interfacce pubbliche stabili, estrazione di due soli servizi davvero distinti (il motore di simulazione e il job worker asincrono basato su Celery + Redis). Il tutto in 4 mesi, con investimento contenuto e nessun impatto sul roadmap prodotto.

Diciotto mesi dopo, l’azienda è cresciuta del 50% mantenendo lo stesso team. La narrativa “less is more” funziona, quando si ha il coraggio di andare controcorrente rispetto alla moda del momento.

Roadmap di scelta architetturale in 60 giorni

Per un CTO o tech lead di PMI italiana che oggi si trova davanti alla decisione, ecco una roadmap concreta in 60 giorni.

FAQ: domande ricorrenti dai CTO PMI nel 2021

1. Possiamo fare microservizi con un team di 10 persone?
Tecnicamente sì, strategicamente no. Sotto i 30 sviluppatori il costo di coordinamento tra servizi supera quasi sempre il beneficio organizzativo. Sotto i 15 sviluppatori è quasi certo che produrrete un distributed monolith.

2. Il modular monolith è davvero scalabile?
Shopify gestisce il Black Friday di 1,7 milioni di merchant su un monolite Rails con refactor modulare in corso. Stack Overflow gestisce miliardi di pagine viste l’anno su un monolite .NET con nove server fisici. La risposta è sì, se fatto bene.

3. Quando è il momento giusto per migrare a microservizi?
Quando la pressione organizzativa supera la capacità di coordinamento del monolite: più team che si bloccano a vicenda, deploy che richiedono coordinamento di 4-5 persone, parti di codice che non si può cambiare per paura di rompere altro. Quando il problema è organizzativo, non quando il problema è tecnico.

4. Kubernetes è obbligatorio per i microservizi?
No, ma nel 2021 è lo standard de facto. Alternative: Docker Swarm (in declino), Nomad di HashiCorp, AWS ECS Fargate per ambienti AWS. Per team senza DevOps maturi, ECS o Fargate riducono drasticamente la complessità operativa.

5. Quanto costa di più una infrastruttura a microservizi?
Tipicamente 2-3x rispetto a un monolite equivalente per carico utente, considerando overhead di orchestrazione, networking, observability, gestione secret, monitoring. Il costo cresce anche in termini di FTE: serve un team di platform engineering dedicato.

6. Cos’è la “majestic monolith” di Basecamp?
Il termine coniato da DHH nel 2020 per descrivere l’approccio Rails di Basecamp: un monolite ben strutturato, gestito da un team piccolo, capace di portare il prodotto HEY a centinaia di migliaia di utenti. È il caso pubblico più forte contro la moda dei microservizi.

7. Possiamo iniziare con microservizi e poi semplificare?
Tecnicamente sì, praticamente quasi mai. La direzione naturale è sempre dal semplice al complesso: iniziare complessi e poi semplificare è un’operazione di refactoring estremamente costosa. La raccomandazione di Sam Newman e Martin Fowler è chiara: monolith first, sempre.