Il Mito dei Microservizi: Non Sono Sempre la Risposta
"Dobbiamo usare i microservizi perché sono moderni". Ho sentito questa frase centinaia di volte, spesso seguita da mesi di caos architetturale.
I microservizi non sono una soluzione universale. Sono una soluzione a problemi specifici. Se non hai quei problemi, hai solo aggiunto complessità senza benefici.
In questo articolo analizzo quando il monolite è ancora la scelta giusta, quando i microservizi risolvono problemi reali, e come migrar gradualmente usando il Strangler Fig Pattern.
Il Monolite: Quando È la Scelta Corretta
Inizia con un monolite ben strutturato. È la scelta giusta se:
- Team < 10 persone
- Traffico < 1000 req/sec
- Budget < €50k per DevOps/Infra
- Dominio meno complesso (non 20+ servizi logici)
Vantaggi del monolite:
- Semplice da debuggare (stack trace continua)
- Deploy rapido (un'unica release)
- Testing facile (no network mocking)
- Performance: zero latenza inter-servizio
- Transazioni ACID naturali (stesso DB)
Contro del monolite:
- Scalabilità: upgradi solo in verticale
- Un bug in un modulo può crashare tutto
- Tech stack unico per tutti i moduli
Microservizi: Quando Hai Davvero Bisogno
Scegli microservizi se:
- Team > 20 persone (Conway's Law)
- Traffico > 10.000 req/sec con picchi
- Diversi moduli che scalano diversamente
- Budget > €100k/year per Kubernetes, monitoring, etc
- Dominio con chiare boundary (pagamenti ≠ notifiche ≠ auth)
Vantaggi microservizi:
- Scalabilità: ogni servizio scala indipendente
- Isolamento: un crash non affecta altri servizi
- Polyglot: ogni team sceglie il suo tech stack
- Deploy indipendente (CD/CI più veloce)
Costi nascosti microservizi:
- Latenza rete: Una call inter-servizio = 50-500ms extra vs 1ms in-process
- Consistenza: ACID morto. Devi usare Saga Pattern (complesso)
- Monitoring: 5 servizi = 5 database, 5 log streams, 5 metriche
- Deploy: 5 servizi con dipendenze = incubo di orchestrazione
- Testing: Integration test con 5 servizi veri = lento e flaky
Ho visto startup con 3 persone usare Kubernetes + 10 microservizi. Risultato: DevOps engineer intero occupato solo a mantenere infra, nessun feature development.
Segnali Che È Ora di Migrare
Se il monolite non crepa, lascialo in pace. Migrare ha costo altissimo. Ma alcuni segnali dicono "è ora":
- Deploy monolite = 45+ minuti (test + build)
- Un team aspetta altro team per deployment (coupling)
- Database overload: una query lenta affecta tutto il sistema
- Tech debt talmente alto che modifiche sono rischiose
- Impossibile scalare: server raggiunge limite fisico
Strangler Fig Pattern: Migrare Senza Riscrivere
Non riscrivere da zero. Usa il Strangler Fig Pattern: costruisci il nuovo servizio accanto al monolite, gradualmente ridirige il traffico.
// Fase 1: Nuovo servizio creato
[Monolite] ← 100% traffico
[Nuovo Servizio] ← 0%
// Fase 2: Ridirige un 10% a nuovo servizio
[Monolite] ← 90% traffico
[Nuovo Servizio] ← 10% traffico
// Fase 3: Monitora errori, ottimizza
[Monolite] ← 50% traffico
[Nuovo Servizio] ← 50% traffico
// Fase 4: Completo
[Monolite] ← 0% traffico (disattiva)
[Nuovo Servizio] ← 100% traffico
Vantaggi:
- Puoi rollback velocemente se il nuovo servizio fallisce
- Testing in produzione con vero traffico
- Zero downtime
- Puoi fare incrementale su mesi/anni
La Mia Raccomandazione
Monolite First. Inizia con un monolite modularizzato:
- Directory separate per ogni modulo logico
- No imports random tra moduli
- Interface ben definite tra moduli
Quando il monolite comincia a soffrire (reale, non anticipato), estrai UN SERVIZIO con Strangler. Non 10 in una volta.
Conclusione
Microservizi vs Monolite non è una scelta religiosa. È una scelta pragmatica basata su:
- Dimensione del team
- Scale reale del traffico
- Budget per infra
- Complessità del dominio
Se tutti e quattro i fattori dicono "microservizi", allora hai un caso d'uso reale. Altrimenti, inizia con monolite e dormi meglio la notte.