ARTICOLO / 29 LUGLIO 2025
FinOps adoption: 7 verità scomode per chi ha smesso di credere alle promesse del cloud
"Sarà più economico del data center. Pagherete solo quello che userete. Direte addio all’over-provisioning."
Quante volte avete sentito queste promesse? E quante volte vi siete ritrovati a guardare le fatture del vostro cloud provider (o dei vostri cloud provider) crescere mensilmente senza riuscire a capire perché?
Nel 2025, la migrazione al cloud non è più una scelta strategica: è un prerequisito per rimanere competitivi. Ma per molte organizzazioni, il cloud computing ha tradito le sue promesse fondamentali. Invece della tanto agognata efficienza economica, si sono ritrovate a far fronte a:
- Costi imprevedibili, con oscillazioni del 30-40% tra un mese e l'altro
- Fatture poco chiare, per cui quasi nessuno sa spiegare perché quella risorsa costi €3.000 al mese
- Over-provisioning in certi casi persino peggiore rispetto al data center (ma almeno nel data center sapevano quanto stavano sprecando)
- Conflitti tra team Finance e IT che si scambiano accuse reciproche mentre i costi continuano a crescere
FinOps non è l'ennesima buzzword su cui occorre prendere una posizione: è l'ultimo tentativo di salvare l’originaria promessa del cloud. Ma funziona solo a patto di guardare in faccia la realtà.
1. La gestione dei costi è un problema di Finance
Il primo errore mortale che si riscontra nelle aziende è dare per assodato che la gestione dei costi cloud sia un problema finanziario. Non lo è. È un problema architetturale travestito da problema di budget. Non è un'opinione, è un dato di fatto supportato dall'esperienza di chi ha ottimizzato centinaia di fatture dei maggiori cloud provider.
Perché moltissime aziende cadono in questo equivoco? Normalmente il Finance guarda la fattura e vede numeri. I tecnici guardano l'architettura e vedono decisioni. I costi del cloud sono conseguenza di scelte architetturali: quale istanza scegliere, come strutturare i dati, quando e come scalare, come gestire il traffico. Il team Finance può ricevere e leggere la fattura, ma non può modificare un'architettura Lambda che genera 100MB di log per richiesta.
Perché continuare a chiedere al CFO di risolvere problemi che solo il CTO può affrontare?
La soluzione, brutalmente semplice, sta in una corretta assegnazione delle responsabilità e nel confronto continuo:
- Assegnare la responsabilità dei costi al team Engineering, supportato dal team Finance.
- Il team Finance si focalizzi su contrattualistica, unit economics e forecasting
- Il team Engineering si concentri su architettura e ottimizzazione
2. Ottimizzazione e gestione dei costi sono la stessa cosa
Smettete di confondere ottimizzazione dei costi con gestione dei costi: è come confondere una dieta equilibrata e ben pianificata con il saltare un pasto per sentirsi meglio con se stessi. La maggior parte delle aziende applica unicamente la gestione dei costi quando invece dovrebbe affiancargli anche un lavoro profondo di ottimizzazione dei costi.
La gestione dei costi è il primo passo, capire dove, chi e come vengono spesi i soldi:
- tagging delle risorse
- dashboard dei costi mensili
- alert su superamente budget
L’ottimizzazione dei costi è il passo successivo, arrivare anche a rivedere profondamente le proprie scelte architetturali:
- riprogettazione dell’infrastruttura e delle applicazioni
- passaggio a servizi serverless
- right-sizing
Il vero FinOps integra entrambi gli approcci, ma pone l'accento sull'ottimizzazione. Non è questione di quanto si spende, ma di quanto valore si ottiene da quella spesa.
3. I silos organizzativi costano soldi
"When organizations don't communicate across teams, share their business context, and work toward common goals, their cloud bill shows it." (FinOps Foundation)
Uno scenario tipico, che probabilmente riconoscerete:
- Il CFO vuole avere visibilità e massima prevedibilità dei costi
- Il CTO vuole avere autonomia e velocità di sviluppo
- Il team di prodotto voleva avere pronte le nuove features, ieri
- Il Board vuole tutto a costo zero, o quasi
Conseguenze? Ogni team ottimizza costi e attività per raggiungere i propri obiettivi, ignorando l'impatto sul resto dell’organizzazione. Il team Finance taglia il budget senza capirne del tutto le implicazioni tecniche. L’Engineering fa scelte architetturali senza considerare il loro impatto economico. Il risultato è una fattura cloud che racconta la storia di un'azienda che non sa dove sta andando.
La formula (non) magica per uscire dall'inferno dei silos:
- Creare un linguaggio comune tra team Finance e team Engineering
- Stabilire obiettivi condivisi che allineino le varie funzioni aziendali
- Implementare processi di comunicazione regolari (non solo quando la fattura esplode!)
- Ogni decisione architetturale deve sempre considerare l'impatto economico atteso ed effettivo
4. Le policy interne sono un colabrodo
Quasi tutte le aziende hanno policy dettagliate per l'acquisto di una spillatrice, ma lasciano che i developer lancino istanze GPU da €50/ora senza alcun controllo. Questo è il paradosso delle policy aziendali nell'era del cloud.
Il problema è che cloud IaaS e SaaS vengono ancora gestiti con mentalità e approccio da data center. Nel data center, una volta acquistato un server il costo era noto. Nel cloud, al contrario, ogni API call, ogni byte trasferito, ogni microsecondo di compute hanno un prezzo.
La soluzione è integrare l’approccio FinOps nelle policy esistenti. Ma Come?
- Coinvolgere Procurement e Software Asset Management nella governance cloud
- Creare processi di approvazione delle spese per risorse che superano soglie economiche definite
- Implementare alert automatici per le spese anomale
- Rendere ogni team tecnico responsabile per i costi che genera
Non si tratta di burocratizzare l'innovazione, ma di rendere visibili le conseguenze economiche delle decisioni tecniche.
5. L’antidoto è la Peer Review
Quante volte una code review ci ha salvato da bug disastrosi finiti in produzione? Ecco, lo stesso principio vale anche per le decisioni di costo: una buona peer review ci garantisce maggiore sicurezza ed evita errori costosi.
Prima di decidere di implementare:
- una nuova architettura a microservizi
- un database NoSQL
- una pipeline di ML che processa terabyte di dati
Vale la pena sempre chiedere a qualcuno con un background non tecnico: "Cosa ne pensi di quanto ci costerà?".
Non è burocrazia, è ingegneria responsabile.
Un processo strutturato di peer review per i costi:
- Previene soluzioni a tunnel che ignorano alternative più economiche
- Condivide conoscenza su best practice di cost optimization
- Crea accountability nelle decisioni architetturali
- Riduce drammaticamente le sorprese in fattura
6. L’IT sa tutto
I team tecnici sono una miniera d'oro di competenze. Spesso sanno già perché quella Lambda costa così tanto, sanno quale servizio sta sprecando banda, sanno dove si sta facendo over-provisioning.
Ma quando è stata l'ultima volta che sono stati coinvolti in una discussione sui costi? Quante volte sono stati coinvolti nella scelta di investire o meno su un progetto di refactoring?
Come ottimizzare il contributo dell’IT in questo contesto:
- Consultare i team tecnici PRIMA di fare cambiamenti significativi al budget cloud
- Coinvolgere attivamente i team tecnici nella definizione di metriche e KPI sui costi
- Valorizzare la competenza dei team nella valutazione di soluzioni alternative
- Invitare i team tecnici a collaborare nella creazione di architetture cost-effective
7. I tool di cost management sono spesso inutili (e hanno un costo)
"Every byte counts, every AZ transfer costs, and somewhere, a cloud service team is probably inventing a new way to charge you for something you thought was free." (Eric Pullen)
La maggior parte dei tool di cost management dei vari cloud provider indicano chiaramente quali risorse incidono sulla fattura, ma non spiegano il contesto o il valore. Cosa serve davvero?
- Un tool che automatizzi l'analisi, non solo la visualizzazione
- Dashboard che mostrino insight operativi, non solo grafici colorati
- Alert intelligenti che distinguano tra anomalie vere e rumore di fondo
- Strumenti integrabili nei processi di engineering, non tool isolati per il team Finance
- Tool che aiutino le aree meno tecniche dell’azienda a gestire le fatture e la rendicontazione sui corretti centri di costo
Ovviamente tutto questo deve necessariamente essere accompagnato da una analisi e una gestione fatta dalle persone, un tool può abilitare decisioni migliori, ma il contributo e le decisioni degli esseri umani restano insostituibili.
Ma quindi cosa dobbiamo fare? Rinunciare?
Abbiamo visto che il FinOps non è una moda, un progetto trimestrale o un’attività one-shot. Ma una pratica da coltivare e sostenere all’interno dell’organizzazione.
L’approccio FinOps è l'unico modo per mantenere davvero le promesse del cloud in un mondo dove ogni decisione tecnica ha conseguenze economiche immediate.
La realtà è che le aziende che non scelgono di implementare il FinOps correttamente, continueranno a pagare le conseguenze economiche di ogni decisione architetturale sbagliata o sconsiderata.
Fortunatamente ci sono anche buone notizie, con la giusta combinazione di:
- Ownership chiare
- Processi di collaborazione strutturati
- Un Tool che abilita insight, non solo semplice reportistica
- L’adozione di una cultura della responsabilità economica nelle decisioni tecniche
- E se necessario un partner che ti affianchi nelle scelte
È possibile trasformare il cloud da costo incomprensibile a vantaggio competitivo misurabile.
La domanda da porsi non è: "Come ridurre i costi cloud?" ma "Come ottimizzare il valore che otteniamo dal cloud?"
Il cloud non è più solo una questione tecnica. È una leva strategica. E il FinOps è il linguaggio comune per farla funzionare.
Autore
Matteo Casanova - Solution Architect