Microservizi vs monolite: quale scegliere nel 2021

Microservizi vs monolite: nel 2021 e’ la domanda architetturale piu’ dibattuta tra CTO, IT manager e developer senior. Da una parte i microservizi, presentati come la soluzione moderna a ogni problema di scalabilita’; dall’altra il vecchio caro monolite, dichiarato “morto” decine di volte e pero’ ancora vivissimo in migliaia di aziende che funzionano benissimo.

La verita’, come spesso accade nell’ingegneria del software, sta nel mezzo. Non esiste un’architettura “giusta” in assoluto: esiste un’architettura giusta per il tuo contesto, in questo momento, con questo team e questo budget. In questa guida vediamo le differenze concrete tra architettura microservizi e architettura monolitica, quando conviene davvero passare ai microservizi, quando il monolite e’ ancora la scelta migliore e quali errori commettono piu’ spesso le PMI italiane quando affrontano questa decisione.

1. Microservizi vs monolite: il dibattito architetturale

Il termine “microservizi” e’ stato reso popolare nel 2014 da Martin Fowler e James Lewis in un articolo diventato pietra miliare. Da allora, soprattutto tra il 2017 e il 2020, i microservizi sono diventati mainstream: Netflix, Amazon, Spotify, Uber e altri giganti hanno raccontato pubblicamente come hanno smontato i loro monoliti per costruire ecosistemi di centinaia (o migliaia) di servizi indipendenti.

Il messaggio che e’ arrivato alle PMI italiane, pero’, si e’ spesso semplificato in slogan pericolosi: “il monolite e’ morto”, “se non fai microservizi sei indietro”, “il cloud richiede microservizi”. Tutti slogan falsi. Nel 2021 la realta’ e’ molto piu’ sfumata: aziende come Shopify, Basecamp, Stack Overflow continuano a usare con orgoglio architetture monolitiche modulari (DHH, creatore di Ruby on Rails, le chiama “majestic monolith”) e il nuovo trend e’ il modular monolith, che cerca di prendere il meglio dei due mondi.

Capire monolite o microservizi non e’ una scelta di moda: e’ una scelta strategica con impatti diretti su costi infrastruttura, velocita’ di sviluppo, complessita’ operativa e capacita’ di scalare il team. Vediamo cosa significa davvero ciascuna delle due opzioni.

2. Cos’e’ un’architettura monolitica (e quando funziona)

Un’architettura monolitica e’ un’applicazione costruita come un singolo blocco unificato: tutto il codice (frontend, backend, logica di business, accesso al database) vive nello stesso codebase, viene compilato e rilasciato come un’unica unita’ deployabile. Esempi tipici nel mondo italiano: un gestionale aziendale in Laravel, un e-commerce Magento, un ERP custom in Java o .NET, una web app Django.

I monoliti hanno una pessima reputazione, ma e’ bene chiarire un punto: “monolite” non significa “spaghetti code”. Un monolite ben fatto puo’ essere modulare, testabile, manutenibile e scalabile per anni. La maggior parte delle applicazioni di successo e’ partita come monolite e per molte di esse il monolite e’ rimasto la scelta migliore anche dopo il successo.

Caratteristiche tipiche di un monolite:

• Un solo codebase, una sola repository, una sola pipeline CI/CD
• Un unico processo runtime (o pochi, se in cluster con load balancer)
• Un database condiviso (tipicamente relazionale: MySQL, PostgreSQL, SQL Server)
• Comunicazione interna tramite chiamate di funzione in-process (zero latenza di rete)
• Deploy “tutto-o-niente”: rilasci l’intera applicazione, non singoli moduli

Quando funziona benissimo? Quando il dominio applicativo e’ coerente, il team e’ piccolo (1-15 sviluppatori), il carico e’ prevedibile e l’azienda non ha esigenze di scalabilita’ selettiva. La maggior parte dei gestionali personalizzati per PMI italiane rientra in questa categoria e funziona perfettamente come monolite.

3. Cos’e’ un’architettura a microservizi

L’architettura microservizi rovescia il paradigma: invece di un singolo blocco, l’applicazione viene scomposta in tanti servizi piccoli, autonomi, ciascuno con una sua responsabilita’ precisa, un suo team, un suo database e un suo ciclo di rilascio indipendente.

Un classico esempio: invece di avere un unico e-commerce monolitico, hai un servizio “catalogo prodotti”, un servizio “carrello”, un servizio “ordini”, un servizio “pagamenti”, un servizio “spedizioni”, un servizio “notifiche email”. Ognuno gira in un suo container, ognuno espone API REST o gRPC, ognuno puo’ essere scritto in un linguaggio diverso, ognuno puo’ essere rilasciato senza toccare gli altri.

Caratteristiche distintive dei microservizi:

• Single responsibility: ogni servizio fa una cosa sola e la fa bene
• Database per service: ogni servizio possiede il suo database, nessuno accede direttamente ai dati altrui
• Comunicazione via rete: API HTTP/REST, gRPC, code di messaggi (RabbitMQ, Kafka)
• Deploy indipendente: rilascio del servizio “ordini” senza toccare “catalogo”
• Team autonomi: un team possiede un servizio dall’inizio alla fine (Conway’s Law applicata)
• Polyglot: liberta’ di usare lo stack tecnologico migliore per ciascun servizio

Wikipedia definisce i microservizi come “un approccio architetturale per la creazione di un’applicazione come insieme di piccoli servizi autonomi, modellati attorno a un dominio di business”. E’ una definizione corretta ma asciutta: la realta’ operativa e’ molto piu’ complessa, come vedremo.

4. Le 7 differenze chiave tra monolite e microservizi

Vediamo in modo concreto le differenze operative tra le due architetture, perche’ e’ qui che si gioca la decisione vera.

4.1 Deployment

Monolite: un solo artefatto da deployare. Una pipeline CI/CD, un solo deploy, semplicita’ operativa massima. Lo svantaggio: se vuoi cambiare una virgola nel modulo “fatturazione” devi rilasciare tutta l’applicazione.
Microservizi: deploy indipendenti per ogni servizio. Cambi solo il servizio “fatturazione” e lo rilasci da solo. Vantaggio enorme per team grandi. Svantaggio: 30 servizi = 30 pipeline CI/CD da gestire.

4.2 Scaling

Monolite: scali tutto insieme (scaling orizzontale dell’intero blocco). Se solo il modulo “ricerca” e’ sotto stress, devi comunque replicare tutta l’app. Inefficiente quando il carico e’ molto sbilanciato tra moduli.
Microservizi: scaling selettivo. Il servizio “ricerca” puo’ avere 20 repliche, “amministrazione” solo 1. Ottimizza l’uso delle risorse cloud. La scalabilita’ software architettura a microservizi e’ qui che brilla davvero.

4.3 Team

Monolite: tutti i developer lavorano sullo stesso codebase. Ottimo fino a 10-15 persone, sopra inizia il caos: merge conflict, rilasci bloccati, decisioni architetturali contese.
Microservizi: ogni team possiede 1-3 servizi (la regola “two-pizza team” di Amazon). Autonomia massima, ma serve cultura e processi maturi.

4.4 Technology stack

Monolite: un solo stack. Cambiare linguaggio significa riscrivere tutto. Vincolo, ma anche coerenza.
Microservizi: liberta’ totale. Servizio A in Node.js, B in Python, C in Go. Vantaggio per casi specifici, ma attenzione alla “zoo tecnologica”: ogni stack richiede competenze diverse, monitoring diverso, sicurezza diversa.

4.5 Data

Monolite: un database condiviso. Transazioni ACID semplici, JOIN tra entita’ immediati, consistenza dei dati garantita dal DB. Modello concettualmente piu’ semplice.
Microservizi: database per service. Niente JOIN tra servizi, transazioni distribuite (Saga pattern), eventual consistency. La gestione dei dati diventa il problema architetturale piu’ complesso.

4.6 Complexity

Monolite: complessita’ tutta dentro il codice (rischio: spaghetti se mal gestito).
Microservizi: complessita’ spostata sull’infrastruttura (Kubernetes, service mesh, distributed tracing, network policies, certificati TLS interni). Il codice di ciascun servizio e’ semplice; l’ecosistema che li tiene insieme e’ molto complesso.

4.7 Communication

Monolite: chiamate di funzione in-process. Zero latenza, debug banale con uno stack trace.
Microservizi: chiamate di rete. Latenza, timeout, retry, circuit breaker, idempotenza, tracciamento distribuito. Un singolo “click utente” puo’ attraversare 10 servizi: capire perche’ qualcosa fallisce diventa un’arte.

5. I 5 vantaggi dei microservizi

I microservizi non sono moda: in certi contesti danno vantaggi reali e misurabili. Ecco i cinque piu’ importanti nel 2021.

1. Scalabilita’ selettiva e ottimizzazione costi cloud: scali solo i servizi che ne hanno bisogno, riduci la spesa AWS/Azure/GCP. Per app con carichi molto sbilanciati (es. e-commerce con picchi sul checkout in Black Friday) puo’ significare risparmi del 30-50%.
2. Indipendenza dei team: 50 sviluppatori in 8 team possono rilasciare in produzione senza coordinarsi tra loro. Velocita’ di sviluppo che un monolite non puo’ eguagliare.
3. Resilienza: un servizio che cade non abbatte tutto il sistema. Se il servizio “wishlist” ha un bug, il checkout continua a funzionare. Con il pattern circuit breaker isoli i fallimenti.
4. Tecnologia ottimale per problema: il servizio “ricerca” puo’ usare Elasticsearch, “raccomandazioni” Python con Pandas, “pagamenti” Java per le librerie bancarie. Niente compromessi tecnologici globali.
5. Riscrittura graduale: vuoi modernizzare un’area legacy? Riscrivi un solo servizio mentre gli altri restano in piedi. Strategia chiamata “strangler fig pattern”, coniata da Martin Fowler.

6. I 5 svantaggi e la complessita’ nascosta

Ora la parte che gli evangelisti dei microservizi sottovalutano sempre. I vantaggi sopra hanno un prezzo molto alto, e per molte PMI italiane il prezzo non e’ giustificato.

1. Complessita’ operativa esplosiva: Kubernetes, Helm, service mesh (Istio/Linkerd), API Gateway (Kong/Tyk), distributed tracing (Jaeger/Zipkin), centralized logging (ELK), service discovery, secret management. Hai bisogno di un team DevOps/SRE dedicato. Costo: 2-4 figure senior aggiuntive.
2. Latenza di rete: chiamate che in un monolite sono nanosecondi, qui sono millisecondi. Una richiesta utente puo’ attraversare 8-12 servizi, ognuno aggiunge latenza. Le performance peggiorano se non disegnate con cura.
3. Distributed transactions: la transazione ACID che davi per scontata sparisce. Devi implementare Saga pattern, compensating transactions, idempotenza. Bug sottili in produzione, difficili da riprodurre.
4. Debugging e osservabilita’: capire perche’ una richiesta e’ lenta in un sistema con 30 servizi richiede strumenti dedicati e cultura ingegneristica matura. “Funziona sul mio PC” non esiste piu’, perche’ nessuno ha 30 servizi sul suo PC.
5. Costo infrastrutturale piu’ alto: ogni servizio e’ un container in piu’, ogni database e’ un costo cloud in piu’, ogni comunicazione di rete genera traffico. Per workload piccoli, un monolite costa molto meno.

Sam Newman, autore di “Building Microservices”, ha sintetizzato bene il punto in una conferenza del 2020: “I microservizi sono uno strumento per gestire la complessita’ organizzativa, non un modo per evitare la complessita’ tecnica. La complessita’ totale aumenta sempre.”

7. Quando scegliere i microservizi (i casi tipici)

I microservizi sono la scelta giusta quando si verificano contemporaneamente piu’ delle seguenti condizioni:

• Team grande: 30+ sviluppatori, organizzati in piu’ team che faticano a coordinarsi su un unico codebase
• Carichi molto sbilanciati: parti del sistema con traffico 100x rispetto ad altre, dove il scaling selettivo paga davvero
• Domini di business chiaramente separati: aree applicative con confini netti, modellabili come bounded context del Domain Driven Design
• Necessita’ di rilasci frequenti e indipendenti: deploy multipli al giorno per area, dove un release train monolitico diventerebbe collo di bottiglia
• Cultura DevOps matura: il team sa gia’ gestire CI/CD, container, monitoring, observability
• Budget infrastrutturale e di personale: hai i soldi per pagare il sovraccarico operativo (almeno 2-3 SRE/DevOps senior)
• Esigenze di stack diversificati: hai problemi che si risolvono molto meglio con linguaggi/runtime specifici diversi

Esempi italiani reali nel 2021: Satispay, Bending Spoons, ShippyPro, Velasca lato backend, alcuni team in Generali e Intesa SanPaolo. Tutte realta’ con team da 50+ developer e carichi che giustificano l’investimento.

8. Quando il monolite e’ ancora la scelta giusta (il “majestic monolith”)

Per la stragrande maggioranza delle PMI italiane, nel 2021, il monolite ben fatto e’ ancora la scelta giusta. DHH (David Heinemeier Hansson), creatore di Ruby on Rails, l’ha chiamato “the majestic monolith” e ha scritto pagine memorabili spiegando perche’ Basecamp continua a essere un monolite Rails dopo 17 anni e milioni di utenti.

Il monolite e’ la scelta giusta quando:

• Il team e’ piccolo (1-15 sviluppatori)
• Il prodotto e’ nelle fasi iniziali (MVP, prodotto-market fit non ancora trovato)
• I confini del dominio non sono ancora chiari (decomporre prematuramente e’ un disastro)
• Il budget operativo non puo’ sostenere infrastrutture complesse
• Le esigenze di scaling sono moderate e prevedibili
• La cultura ingegneristica e’ acerba sui temi DevOps/observability

Errore tipico: una PMI con 5 sviluppatori che decide di “partire microservizi dall’inizio perche’ tanto cresceremo”. Risultato quasi garantito: progetto in ritardo di 6-12 mesi, costi cloud tripli, sviluppatori che spendono il 60% del tempo a debuggare problemi distribuiti invece di costruire feature di business. Le web app e PWA per PMI partono quasi sempre come monoliti, ed e’ la scelta corretta.

9. Il pattern intermedio: modular monolith

La grande riscoperta del 2020-2021 e’ il modular monolith: un monolite organizzato internamente in moduli con confini netti (come fossero microservizi), ma deployato come singolo artefatto. E’ la scelta che molti team consigliano oggi come default per progetti nuovi, soprattutto in PMI.

Caratteristiche del modular monolith:

• Un solo deploy, un solo database (semplicita’ operativa)
• Codice organizzato per bounded context (DDD): modulo “ordini” non puo’ chiamare direttamente codice del modulo “magazzino”, deve passare da API interne
• Database con schemi separati per modulo (logica di “database per service” applicata internamente)
• Pronto per essere “spezzato” in microservizi se e quando servira’ davvero

Stack tipici nel 2021: Laravel con moduli ben separati, Spring Boot con multi-module Maven, .NET con Clean Architecture e bounded context. Aziende come Shopify (Ruby on Rails) hanno reso famoso questo approccio dimostrando che si puo’ arrivare a centinaia di milioni di utenti con un monolite ben organizzato.

Il modular monolith e’ la scelta che noi di Brentasoft suggeriamo nel 95% dei progetti per PMI italiane. Ti da i benefici della modularita’ (codice pulito, team che lavorano in parallelo) senza il costo dei microservizi (DevOps complesso, latenza, transazioni distribuite).

10. Tecnologie 2021 per microservizi (Docker, Kubernetes, service mesh)

Se hai deciso che i microservizi fanno per te, ecco lo stack tecnologico mainstream nel 2021. Conoscerlo aiuta anche a misurare il costo dell’investimento.

Containerizzazione e orchestrazione:

• Docker: ormai standard di fatto, ogni microservizio gira in un container
• Kubernetes: orchestratore dominante (oltre l’80% del mercato secondo CNCF Survey 2020). Gestisce scheduling, scaling, self-healing dei container
• Managed Kubernetes: AWS EKS, Azure AKS, Google GKE. Eviti di gestire il control plane, paghi un sovrapprezzo
• Alternative serverless: AWS ECS Fargate, Azure Container Instances, Google Cloud Run per workload meno orchestrati

Service mesh (gestione comunicazione tra servizi):

• Istio: il piu’ diffuso, ricco ma complesso. Gestisce mTLS, traffic management, observability
• Linkerd: piu’ leggero, ottimo per team che non vogliono la complessita’ di Istio
• Consul Connect (HashiCorp): integrato con Consul per service discovery

API Gateway:

• Kong: open source, basato su Nginx, plugin ecosystem ricco
• Tyk: alternativa europea, ottima documentazione
• AWS API Gateway, Azure API Management, Google Apigee: managed services dei cloud provider

Comunicazione asincrona: RabbitMQ, Apache Kafka, AWS SQS/SNS. Per pattern come event-driven architecture e Saga.

Observability stack: Prometheus + Grafana per metriche, ELK (Elasticsearch + Logstash + Kibana) per logging centralizzato, Jaeger o Zipkin per distributed tracing, Sentry per error tracking. Per integrazione API tra microservizi e sistemi esterni: OpenAPI/Swagger per i contratti, AsyncAPI per gli eventi.

Questo stack e’ potente ma costoso da padroneggiare. Aspettati 6-12 mesi prima che un team senza esperienza precedente lo gestisca con fluidita’.

11. Errori frequenti delle PMI quando passano a microservizi

Negli ultimi 4 anni abbiamo visto decine di PMI italiane intraprendere il viaggio verso i microservizi, spesso con risultati deludenti. Ecco gli errori piu’ frequenti, in ordine di pericolosita’.

1. Iniziare con i microservizi un progetto greenfield. Senza un dominio chiaro, decomponi su confini sbagliati. Risultato: distributed monolith, il peggio dei due mondi. La regola di Martin Fowler “monolith first” resta valida.

2. Spezzare il monolite per moda, non per necessita’. Se non hai un problema concreto che il monolite non puo’ risolvere, il refactoring verso microservizi e’ uno spreco. “Migliorare il codice” non e’ una motivazione sufficiente.

3. Decomporre per layer tecnologico invece che per dominio. Errore classico: un servizio “database”, uno “frontend”, uno “backend”. Sbagliato: i confini devono seguire il business, non l’architettura tecnica.

4. Database condiviso tra microservizi. “Tanto risparmiamo costi”. No: appena due servizi accedono allo stesso DB hai un monolite mascherato, peggio del precedente.

5. Sottovalutare il costo DevOps. Pensare che bastino 2 sviluppatori per gestire Kubernetes in produzione 24/7. Spoiler: non basta. Servono SRE dedicati, on-call rotation, runbook.

6. Non investire in observability. Senza tracing distribuito e logging centralizzato, un sistema a microservizi e’ debugabile come una macchina nera in fiamme. Strumenti dal giorno uno, non dopo il primo incidente.

7. Decomporre senza modello dei dati. Senza Domain Driven Design e bounded context, ti ritrovi a fare JOIN distribuiti tra 5 servizi per mostrare una pagina. Performance disastrose.

Una soluzione cloud aziendale ben fatta ti permette di iniziare con un monolite, scalarlo orizzontalmente, e migrare gradualmente verso microservizi solo dove e quando serve davvero. E’ la strada che consigliamo alle PMI italiane nel 2021.

12. Domande frequenti

I microservizi sono sempre piu’ veloci di un monolite?

No, anzi: nella maggior parte dei casi sono piu’ lenti per singola richiesta a causa della latenza di rete. Sono piu’ performanti su throughput aggregato grazie al scaling selettivo e parallelo. La velocita’ percepita dall’utente dipende molto dal disegno architetturale.

Quanto costa passare da monolite a microservizi per una PMI?

Per una PMI italiana media (gestionale interno, 10-30k linee di codice, 5-10 utenti concorrenti) il costo realistico e’ tra 80.000 e 250.000 euro nel primo anno, considerando refactoring, infrastruttura cloud aggiuntiva, formazione team, eventuali consulenze esterne. Ed e’ un costo che spesso non porta benefici proporzionati.

Kubernetes e’ obbligatorio per i microservizi?

No. Si possono fare microservizi anche con Docker Swarm, AWS ECS, Nomad di HashiCorp, o servizi managed come AWS App Runner o Google Cloud Run. Kubernetes e’ lo standard di fatto, ma per piccoli numeri di servizi alternative piu’ semplici sono spesso preferibili.

Posso fare microservizi senza cloud?

Tecnicamente si’, ma e’ molto piu’ costoso e complesso. Il cloud (con servizi managed di Kubernetes, database, code, observability) abbatte drasticamente il costo operativo. Microservizi on-premise nel 2021 hanno senso solo per ragioni di compliance/sovranita’ del dato molto stringenti.

Quanti microservizi sono “troppi”?

Non c’e’ un numero magico, ma una regola empirica: meno servizi che team e’ generalmente sano (1-3 servizi per team). Se hai 100 servizi e 10 sviluppatori, hai un problema (lo stesso vale al contrario: 1 servizio per 50 developer e’ un altro problema).

Modular monolith o microservizi? Quale scelgo nel 2021?

Se sei una PMI con meno di 30 sviluppatori e non hai problemi di scaling concreti misurati, modular monolith. Quasi sempre. Puoi sempre migrare verso microservizi dopo, quando avrai dati e necessita’ reali, non ipotetiche. Il viaggio inverso (microservizi -> monolite) e’ invece quasi sempre doloroso.

Conclusione: la decisione e’ di contesto, non ideologica

Tornando alla domanda iniziale: microservizi vs monolite? La risposta seria e’ “dipende”. Dipende dal team, dal dominio, dal carico, dal budget, dalla maturita’ DevOps. Chiunque ti dica “microservizi sempre” o “monolite sempre” sta vendendo dogmi, non architettura.

Nel 2021, la nostra raccomandazione per la maggior parte delle PMI italiane e’ chiara: parti modular monolith, costruisci confini puliti tra moduli, misura, e migra a microservizi solo gli specifici componenti che hanno bisogno reale di scalabilita’ indipendente o team autonomi. Eviterai mesi di sofferenza inutile e arriverai prima sul mercato.

Se vuoi approfondire i temi correlati: abbiamo scritto una guida completa su sviluppo software custom per PMI: quando conviene davvero e su SaaS vs on-premise per PMI, due decisioni architetturali strettamente collegate alla scelta tra monolite e microservizi.