Scalabilità sì, ma a che costo? Il vero ROI delle architetture distribuite

Negli ultimi anni ho visto un numero crescente di aziende inseguire architetture distribuite come se fossero un badge di modernità: microservizi ovunque, code e stream per qualsiasi cosa, tre livelli di caching, cinque database diversi e un diagramma architetturale che sembra più un quadro astratto che un sistema informativo.

Il problema è che la complessità si paga, sempre.
Non solo in infrastruttura, ma in persone, processi, incidenti, time-to-market.

La tesi che mi sono fatto negli anni, tra monoliti “tirati al massimo” e sistemi distribuiti spinti, è questa:

Non tutto ciò che scala ha senso: la semplicità resta una strategia di business.

Quello che segue è il mio modo di ragionare sul ROI delle architetture distribuite: quando ha senso complicarsi la vita, quando no, e come misurare se stiamo davvero facendo una scelta intelligente o solo seguendo l’ennesima moda tech.

Perché le aziende sovra-ingegnerizzano

Prima di parlare di ROI, dobbiamo essere onesti su un punto:
molta della complessità che vediamo in giro non nasce da esigenze reali di scalabilità.

I motivi (molto umani) della complessità

Le aziende (e le persone) sovra-ingegnerizzano per una combinazione di fattori:

• Vanità tecnica
  È molto più sexy raccontare “abbiamo 40 microservizi in Kubernetes” che “abbiamo un monolite noioso ma solido che stampa soldi”.

• FOMO architetturale
  “Se non abbiamo Kafka / microservizi / CQRS / event sourcing, siamo indietro”.
  La paura di essere percepiti come “vecchi” tecnologicamente porta a introdurre tool e pattern che non servono davvero.

• Overdesign difensivo
  “Facciamo tutto distribuito fin da subito, così siamo pronti a crescere”.
  Tradotto: ottimizziamo ora per un problema che forse non avremo mai, pagando costi da subito.

• Influenza dei vendor
  Il cloud provider o il partner di turno ha tutto l’interesse a spingere soluzioni più complesse = più servizi = più fatturato.

• Organizzazione a silos
  Quando i team crescono e si specializzano, ogni gruppo tende a “tirare dentro” il proprio tool, il proprio database, il proprio pattern. Risultato: un zoo tecnologico difficile da governare.

La domanda che manca

Quasi mai sento fare la domanda che dovrebbe stare sopra a tutte:

“Questa complessità in più, quanto ci fa guadagnare o risparmiare davvero?”

Finché non si collega la scelta architetturale a un effetto economico misurabile, stiamo facendo filosofia, non ingegneria al servizio del business.

Come valutare il ROI architetturale

Parlare di ROI per un’architettura può sembrare astratto, ma non lo è.
L’idea di base è semplice:

Ogni pezzo di complessità in più deve avere un ritorno: in ricavi, in costi evitati, in rischio ridotto.

Passo 1 – Farsi le domande giuste

Ogni volta che qualcuno propone di “distribuire”, spezzare, mettere in coda, streammare tutto, io mentalmente passo da qui:

1. Quale problema concreto stiamo risolvendo?

   • Performance?
   • Affidabilità?
   • Time-to-market di team diversi?
   • Compliance / separazione dei dati?

2. Cosa succede se NON facciamo questo cambiamento?

   • Perdiamo clienti?
   • Rallentiamo lo sviluppo?
   • Aumenta il rischio di downtime?
   • Oppure… non succede granché?

3. Quanto ci costa mantenerlo nei prossimi 3 anni?

   • In infrastruttura.
   • In formazione del team.
   • In complessità cognitiva.
   • In incidenti più difficili da debuggare.

Se non riesco a rispondere decentemente a queste domande, la mia default strategy è: non toccare, o toccare il minimo indispensabile.

Passo 2 – Pensare a scenari, non a feature

Non basta dire “microservizi = più scalabilità”.
Bisogna ragionare per scenari:

• Se il traffico raddoppia in 6 mesi, questa architettura cosa mi permette di fare che oggi non posso fare?
• Se devo lanciare un nuovo prodotto, questo design mi fa andare online in 2 settimane invece che in 2 mesi?
• Se mi cade un pezzo, quanto perdo, per quanto tempo, e con che impatto sul fatturato?

L’architettura è un abilitatore o un freno per gli scenari di business?
Lì si misura il ROI.

Metriche utili e KPI concreti

Per non rimanere nel vago, quando valuto la bontà (o l’eccesso) di un’architettura distribuita, guardo a un mix di metriche tecniche e business.

KPI di business collegati all’architettura

• Costo totale di esercizio per funzionalità core
  Quanto ci costa, tutto compreso (infra + persone), tenere in piedi la parte del sistema che genera l’80% del fatturato?

• Tempo medio di delivery di una nuova feature
  Quanti step, quanti team, quante pipeline devo toccare per mettere in produzione una modifica “banale”?
  Se una modifica a un flusso utente tocca 7 microservizi, forse stiamo pagando troppo la nostra decomposizione.

• Costo di onboarding di un nuovo sviluppatore
  Quante settimane servono prima che una persona nuova riesca a contribuire senza rompersi la testa sulla complessità del sistema?

• Impatto economico medio di un incidente
  Un’architettura distribuita promette resilienza. Se però ogni incidente costa di più perché è più complesso da analizzare, c’è un problema.

Metriche tecniche che non sono solo “nerd stuff”

• MTTR (Mean Time To Recovery)
  Quanto tempo serve per capire cosa sta succedendo e rimettere in piedi il servizio?
  Una buona architettura distribuita dovrebbe migliorare l’MTTR, non peggiorarlo.

• Numero di boundary critici
  Quanti hop di rete, quanti servizi e quanti datastore stanno nel percorso di una singola chiamata utente? Più salti ci sono, più stai giocando alla roulette con la complessità.

• Coupling organizzativo
  Quante squad devi allineare per fare un cambiamento?
  Se “distribuito” significa “più dipendenze tra team”, c’è qualcosa che non torna.

Il punto chiave è questo:

Una metrica tecnica ha valore solo se riesci a collegarla a un effetto sul conto economico o sul rischio di business.

Quando la complessità si paga… e quando no

Arriviamo alle scelte difficili: quando ha senso accettare una maggiore complessità architetturale?

Quando la complessità ha un ROI positivo

Di solito, vale la pena complicarsi la vita quando:

• Hai un chiaro “scaling story” già in atto, non solo ipotetica
  Il traffico, il numero di clienti o il volume di dati stanno crescendo in modo misurabile, e il collo di bottiglia è reale, non solo temuto.

• Hai più team che devono lavorare in parallelo sullo stesso dominio
  Spezzare il monolite può avere molto senso quando la complessità organizzativa è già esplosa.
  In quel caso, il ROI è nella velocità di sviluppo, non solo nelle performance.

• La resilienza ha un valore economico diretto
  Se 10 minuti di downtime ti costano centinaia di migliaia di euro, investire in architetture distribuite con failover più sofisticati può avere perfettamente senso.

• Hai la maturità (people + process) per sostenerla
  Monitoring, SRE, incident management, cultura della responsabilità end-to-end.
  L’architettura distribuita senza questi elementi è solo un modo più costoso di rompersi.

Quando la complessità NON si paga

Dall’altra parte, vedo spesso casi in cui la complessità è puro debito mascherato da “modernità”:

• Startup early stage con traffico modesto che partono direttamente con 30 microservizi e 5 database “perché così siamo pronti”.
  Risultato: non sono pronti per i clienti, sono pronti per gli incidenti.

• PMI che non hanno team specializzati, ma adottano stack distribuiti come se avessero un reparto SRE dedicato.

• Prodotti che cambiano spesso direzione, ma hanno un’architettura talmente rigida e frammentata da rendere ogni pivot un incubo.

In tutti questi casi, una soluzione più semplice – anche “imperfetta” – avrebbe spesso un ROI migliore nel medio periodo.

Conclusione: la semplicità come strategia di business

Alla fine, per me la domanda non è “monolite vs microservizi”, “distribuito vs centralizzato”, “Kafka sì o no”.

La domanda vera è:

“Questa decisione architetturale rende il nostro business più robusto, più veloce o più redditizio… oppure solo più complicato?”

La semplicità non è il contrario della scalabilità.
È una forma diversa di intelligenza strategica:

• ritardare la complessità finché non è strettamente necessaria;
• introdurla solo dove è chiaramente pagata (dal mercato, non dall’ego tecnico);
• accettare che alcune soluzioni “banali” siano in realtà perfettamente adeguate.

In altre parole:
non tutto ciò che scala ha senso.
Ma tutto ciò che ha senso, prima o poi, deve dimostrare il suo valore anche fuori dalle slide architetturali.

E lì, il ROI delle architetture distribuite si vede molto bene.