Microservizi vs Monolite: Analisi costi-benefici
Era il classico business "noioso" che piace agli investitori: una piattaforma B2B per gestire appuntamenti, ordini e pagamenti per una nicchia specifica di professionisti.
Modello prevedibile. Traffico costante. Nessun picco improvviso stile Black Friday. Nessuna esigenza di calcolo distribuito.
Sulla carta, il candidato perfetto per una "Noiosa Architettura Monolitica" o, al massimo, un backend serverless ben strutturato. Costo di gestione: poche centinaia di euro al mese.
Invece, quando mi hanno mostrato il diagramma architetturale, ho pensato fosse uno scherzo.
Il Miraggio dell'Enterprise
L'agenzia esterna che li aveva seguiti nella fase 1 aveva fatto un lavoro "da manuale". Purtroppo, il manuale era quello sbagliato.
Avevano messo in piedi un mostro a 12 teste:
- Microservizi spinti: Ogni singola entità (Utenti, Ordini, Pagamenti, Notifiche) era un servizio a sé stante.
- Container Orchestration: Un cluster Kubernetes sovradimensionato per gestire... 50 utenti concorrenti.
- Service Mesh: Perché "non si sa mai che un giorno dobbiamo scalare come Uber".
- Code distribuite: RabbitMQ per passare messaggi tra servizi che avrebbero potuto semplicemente essere funzioni nello stesso file.
Il fondatore era orgoglioso: "Abbiamo un'architettura all'avanguardia, pronta per scalare a milioni di utenti."
Gli ho dovuto dare la brutta notizia: "Non hai un'architettura pronta per scalare. Hai un'architettura pronta per fallire."
Il Prezzo della Complessità Inutile
Il problema non era solo il costo AWS mensile (che comunque era 10 volte il necessario). Il problema era l'attrito.
Volevano aggiungere una semplice feature: permettere ai professionisti di caricare un logo personalizzato nella fattura.
In un sistema normale?
- Aggiungi colonna al DB.
- Aggiorni l'API endpoint.
- Aggiorni il frontend.
- Deploy. Tempo totale: 4 ore.
Nel loro "Sistema Enterprise"? Bisognava coordinare il servizio Utenti, il servizio Fatturazione, aggiornare i contratti di interfaccia, redeployare 3 container diversi, gestire la retrocompatibilità dei messaggi in coda...
Risultato: 2 settimane di lavoro e 3 bug di regressione introdotti.
"Non si può sistemare"
Quando mi hanno chiamato, la situazione era critica. Volevano correre, ma avevano le gambe legate dal cemento che loro stessi (o meglio, i loro fornitori) avevano colato.
Mi hanno chiesto: "Manuel, come ottimizziamo questo sistema?"
Ho guardato i numeri. Ho guardato il codice. Ho guardato il team, esausto e frustrato.
E ho detto la verità più scomoda di tutte:
"Avete costruito una Formula 1 per consegnare le pizze in centro a Milano. E ora vi lamentate che non trovate parcheggio e che i ricambi costano troppo."
E la parte peggiore? Non si poteva ottimizzare. Non puoi trasformare una Formula 1 in uno scooter agendo sui settaggi. Devi cambiare veicolo.
L'unica strada percorribile era rifare le fondamenta. Tornare indietro. Semplificare. Accorpare i servizi. Eliminare Kubernetes.
Il Costo Nascosto del Rebuild
Rifare tutto non significa solo riscrivere il codice. Significa migrare i dati. Significa fermare lo sviluppo di nuove feature per mesi. Significa spiegare agli investitori perché state spendendo soldi per tornare al punto di partenza invece di crescere.
Tutto questo dolore poteva essere evitato con una domanda semplice all'inizio del progetto: "Qual è la soluzione più semplice che funziona oggi?"
Invece, si sono fatti sedurre dalla vanità tecnica. "Facciamolo scalabile" è diventato "Facciamolo complicato".
La Lezione
Non accettare mai complessità che non puoi giustificare con un problema attuale e misurabile.
Se qualcuno ti propone microservizi, Kubernetes o architetture esotiche per una startup che non ha ancora validato il mercato, scappa. O meglio, chiamami prima di firmare quel contratto.
Perché costruire un sistema che "potrebbe" gestire un milione di utenti è il modo migliore per non arrivarci mai, a quel milione.