La promessa dei microservizi
I microservizi sono nati per risolvere problemi reali: team grandi che si bloccano a vicenda su un monolite, necessità di scalare componenti indipendentemente, possibilità di deployare una feature senza deployare tutto il sistema.
Per Netflix, Amazon, Google queste esigenze erano — e sono — reali. Hanno migliaia di ingegneri, decine di team, workload con picchi imprevedibili. I microservizi erano la risposta giusta per loro.
Il problema è che questa soluzione è stata adottata da aziende con 5, 10, 20 ingegneri — organizzazioni per cui i problemi dei microservizi superano i benefici di gran lunga.
I costi nascosti dei microservizi
Ogni chiamata tra servizi è una chiamata di rete. Non c'è transazione atomica. Non c'è stack trace unico. Questi non sono dettagli implementativi — sono cambiamenti fondamentali nel modo in cui i sistemi falliscono e vengono debuggati.
- Overhead di rete e latenza accumulata: una richiesta che in un monolite attraversa il codice in memoria in pochi millisecondi, in un sistema a microservizi attraversa la rete più volte. La latenza si accumula, i fallimenti si propagano a cascata.
- Consistenza eventuale: in un sistema distribuito non esiste la transazione atomica tra servizi. Gestire la coerenza dei dati richiede pattern complessi come saga, outbox pattern e CQRS — che molti team non conoscono a sufficienza.
- DevOps overhead: orchestrazione (Kubernetes), service mesh, distributed tracing, log aggregation. Un team di 8 persone che gestisce 20 microservizi passa più tempo a gestire infrastruttura che a costruire prodotto.
- Debugging distribuito: trovare la causa di un errore in un sistema con 15 servizi interconnessi, ciascuno con i propri log, è un'operazione che può richiedere ore — contro minuti in un monolite ben strutturato.
I microservizi risolvono problemi di scala organizzativa prima che problemi di scala tecnica. Se non hai il problema di coordinare decine di team su una stessa codebase, probabilmente non hai bisogno dei microservizi.
Il ritorno del monolite modulare
Aziende come Shopify, Stack Overflow e Basecamp non hanno mai abbandonato il monolite. Hanno costruito architetture modulari interne — moduli con confini netti, dipendenze controllate, interfacce esplicite — senza i costi della distribuzione.
Il modular monolith (o "majestic monolith", come lo chiama David Heinemeier Hansson) è un'architettura legittima, non un compromesso. Per la maggior parte delle aziende con team sotto le 30-40 persone di engineering, è spesso la scelta più sensata.
Microservizi: quando ha senso
- Team di 50+ ingegneri su una stessa base di codice
- Componenti con requisiti di scaling radicalmente diversi
- Team autonomi che deployano indipendentemente
- Workload con picchi imprevedibili e molto variabili
Monolite modulare: quando ha senso
- Team sotto le 30 persone di engineering
- Necessità di transazioni ACID tra entità correlate
- Startup o prodotti ancora in phase di product discovery
- Quando il debugging e la manutenibilità sono priorità
Il pendolo del cloud: perché le aziende tornano on-premise
Parallela alla rivalutazione dei microservizi, c'è una rivalutazione del cloud pubblico. Il fenomeno si chiama cloud repatriation ed è documentato da Gartner e da diversi casi pubblici di alto profilo (37signals, QUIC.cloud e altri).
I driver del ritorno on-premise
Costi reali vs costi attesi: AWS, Azure, GCP hanno costi certi in ingresso ma molto variabili in uscita. L'egress pricing — quanto paghi per portare i tuoi dati fuori dal cloud — può diventare una voce di costo significativa ad alta scala. Workload stabili e prevedibili costano spesso il 40-60% in meno su hardware proprio.
Sovranità del dato: GDPR e normative settoriali (healthcare, finance, difesa, PA) spingono verso soluzioni on-premise o private cloud su datacenter certificati in territorio europeo. Non è paranoia — è compliance.
Latenza verso impianti fisici: per workload real-time che devono stare vicini agli impianti fisici — sistema di controllo industriale, edge computing, sistemi embedded connessi — un datacenter privato può offrire latenze che il cloud non può garantire strutturalmente.
Il cloud non è la risposta giusta per tutto. È la risposta giusta per workload variabili, per burst capacity, per servizi gestiti che non ha senso operare internamente. Per workload stabili e prevedibili, la matematica spesso non torna.
Hybrid è la risposta, non la scelta tra A e B
La risposta non è tornare completamente ai datacenter privati, né restare tutto cloud pubblico. È riconoscere che cloud pubblico, cloud privato e on-premise non sono alternative mutuamente esclusive — sono strumenti per workload diverse:
- Cloud pubblico: burst capacity, servizi gestiti (ML, CDN, DNS, email), disaster recovery, ambienti di sviluppo e staging
- Datacenter privato: workload stabili e prevedibili, dato sensibile che non può uscire dall'azienda, bassa latenza verso impianti fisici
- Edge: elaborazione locale in tempo reale, resilienza alla disconnessione, decisioni a bassa latenza
Come progettiamo in Blueware
Progettiamo architetture cloud-agnostic dall'inizio. I dati e la logica applicativa non devono essere legati a un provider. Se l'azienda decide di spostare una workload da cloud pubblico a on-premise — o viceversa — l'architettura lo deve permettere senza riscrivere tutto.
Questo non è dogmatismo anti-cloud: è rispetto per la capacità dell'azienda di scegliere liberamente in futuro. I lock-in costano sempre — la domanda è solo quando si paga il conto.