{"id":8097,"date":"2025-10-22T11:13:45","date_gmt":"2025-10-22T09:13:45","guid":{"rendered":"https:\/\/blog.besharp.it\/?p=8097"},"modified":"2025-10-22T11:51:05","modified_gmt":"2025-10-22T09:51:05","slug":"anti-pattern-finops-cosa-non-fare-per-avere-piu-budget-per-innovare","status":"publish","type":"post","link":"https:\/\/blog.besharp.it\/it\/anti-pattern-finops-cosa-non-fare-per-avere-piu-budget-per-innovare\/","title":{"rendered":"Anti-pattern FinOps: cosa (non) fare per avere pi\u00f9 budget per innovare"},"content":{"rendered":"\n
Eccoci con un altro portmanteau tra “qualcosa<\/em>” e Operations.<\/em> Questa volta tocca al tema Finance.<\/p>\n\n\n\n Generalmente, il primo impatto con il termine FinOps<\/strong> \u00e8 affrontato con una certa superficialit\u00e0: si da per scontato che se Operations<\/em> riguarda l\u2019infrastruttura e Finance<\/em> significa \u201c$$\u201d, allora l\u2019unione delle due deve per forza voler dire \u201cridurre gli sprechi nel cloud\u201d<\/em>. <\/p>\n\n\n\n Giusto?\u00a0 Per fugare ogni dubbio \u00e8 il caso di spendere un paragrafo per spiegare a grandi linee alcuni concetti di FinOps. Se li conosci gi\u00e0 sentiti libero di saltarlo \ud83d\ude42<\/p>\n\n\n\n Prima di tutto, vale la pena chiarire un punto fondamentale: FinOps non introduce concetti rivoluzionari. \u00c8 piuttosto un modo strutturato di riportare in primo piano l\u2019attenzione all\u2019efficienza. Il framework nasce con l\u2019obiettivo di massimizzare il valore di business del cloud, abilitando decisioni rapide e guidate dai dati e creando una responsabilit\u00e0 finanziaria condivisa tra ingegneria, finanza e business. In questo senso, rappresenta un vero e proprio cambio di paradigma: la gestione dei costi non \u00e8 pi\u00f9 un\u2019attivit\u00e0 di consuntivo, ma diventa parte integrante dei processi decisionali quotidiani.<\/p>\n\n\n\n Il percorso FinOps si articola in tre fasi iterative che si alimentano a vicenda: Inform<\/strong>, Optimize<\/strong> e Operate<\/strong>.<\/p>\n\n\n\n <\/p>\n\n\n <\/p>\n\n\n\n Nella fase di Inform<\/strong>, l\u2019attenzione \u00e8 rivolta alla raccolta e alla valorizzazione dei dati relativi a costi, utilizzo ed efficienza del cloud. Questi dati vengono trasformati in strumenti di analisi e reportistica capaci di offrire una visibilit\u00e0 accurata sulle dinamiche di spesa. Ne derivano capacit\u00e0 di budgeting e di previsione, ma anche la possibilit\u00e0 di misurare le performance attraverso KPI e benchmark interni o esterni. La natura elastica e on-demand del cloud, insieme ai meccanismi di sconto, rende indispensabile un monitoraggio continuo: solo con informazioni tempestive \u00e8 possibile anticipare la spesa, prevenire sorprese e mantenere un ritorno sull\u2019investimento coerente con gli obiettivi aziendali.<\/p>\n\n\n\n La fase di Optimize<\/strong> si concentra invece sull\u2019efficientamento. \u00c8 il momento in cui i dati raccolti vengono utilizzati per individuare opportunit\u00e0 concrete di ottimizzazione, ad esempio ridimensionando le risorse sottoutilizzate, adottando architetture pi\u00f9 moderne, automatizzando la gestione dei carichi di lavoro e riducendo gli sprechi. Anche le tariffe diventano un campo di ottimizzazione, grazie a modelli di sconto come Reserved Instances e Savings Plans. Questa fase non si limita a tagliare i costi, ma punta a un dialogo continuo tra i diversi team, cos\u00ec da garantire che le prestazioni del cloud restino sempre allineate agli obiettivi strategici dell\u2019organizzazione.<\/p>\n\n\n\n Infine, nella fase di Operate<\/strong> si consolidano i cambiamenti. Qui trovano spazio la definizione di politiche di governance, il monitoraggio della conformit\u00e0, la responsabilizzazione delle persone e la diffusione di una cultura della responsabilit\u00e0 condivisa. I team tecnici, finanziari e commerciali collaborano in maniera costante, prendendo decisioni iterative e incrementali basate sulle evidenze raccolte nelle fasi precedenti. L\u2019approccio \u00e8 ciclico: ogni azione porta a nuove informazioni, che alimentano ulteriori ottimizzazioni e rendono i processi pi\u00f9 maturi e consapevoli.<\/p>\n\n\n\n Il valore di FinOps sta proprio in questo ciclo continuo. Informare, ottimizzare e operare non sono momenti isolati, ma fasi che si intrecciano e si ripetono, portando l\u2019organizzazione a una gestione del cloud sempre pi\u00f9 evoluta e capace di generare valore concreto.<\/p>\n\n\n\n Ora che abbiamo chiarito cosa sia FinOps e come funzioni, vediamo dove le cose possono andare storte. In quanto consulenti, non siamo certo nuovi a situazioni disperate. A volte per\u00f2, gli errori pi\u00f9 subdoli non si manifestano subito: restano silenziosi durante le fasi di progettazione e implementazione per poi rivelarsi solo dopo il rilascio in produzione. Ed \u00e8 proprio l\u00ec, quando l’infrastruttura comincia a scalare e i costi aumentano, che ormai \u00e8 troppo tardi per intervenire e il conto (letteralmente) arriva.<\/p>\n\n\n\n Questi errori sono la conseguenza di progettazioni che hanno considerato solo i requisiti tecnici, ignorando (o trattando superficialmente) l’impatto economico delle scelte architetturali. Un approccio che contrasta con lo “shift-left” dei costi: portare la consapevolezza finanziaria fin dalle prime fasi di progettazione, quando le decisioni possono ancora fare la differenza.<\/p>\n\n\n\n Diciamocelo: il concetto del serverless \u00e8 affascinante.<\/p>\n\n\n\n L\u2019idea di non dover gestire infrastruttura (n\u00e9 sistemisti!) \u00e8 il sogno di ogni sviluppatore.<\/p>\n\n\n\n E cos\u00ec, complici la facilit\u00e0 d\u2019uso e la scalabilit\u00e0 automatica, si finisce spesso per scegliere un\u2019architettura serverless anche quando non \u00e8 la scelta pi\u00f9 adatta.<\/p>\n\n\n\n <\/p>\n\n\n <\/p>\n\n\n\n Per poter prendere delle decisioni informate \u00e8 necessario avere chiari i casi d\u2019uso.<\/p>\n\n\n\n Il serverless \u00e8 perfetto per:<\/p>\n\n\n\n \u00c8 il caso di farsi qualche domanda in pi\u00f9 nel caso in cui si abbiano:<\/p>\n\n\n\n Prendiamo come esempio una versione opportunamente semplificata del confronto tra i costi running di una Lambda Function e di una macchina EC2. Come si pu\u00f2 immaginare i costi della Lambda crescono pi\u00f9 o meno linearmente con il tempo di utilizzo, mentre i costi della macchina EC2 di un certo taglio sempre accesa sono fissi. Inoltre \u00e8 importante considerare che l\u2019EC2 in esempio ha una maggiore potenza computazionale e un disco.<\/p>\n\n\n\n <\/p>\n\n\n <\/p>\n\n\n\n Chiaramente questo ragionamento salta se il carico di lavoro varia molto nel tempo. Una macchina EC2 sempre accesa ha dei costi infinitamente maggiori di una Lambda eseguita sporadicamente.<\/p>\n\n\n\n Pi\u00f9 in generale, il Modeling<\/em> \u00e8 un principio cardine del FinOps che impone di modellare il profilo di carico e l’andamento dei costi nel tempo prima di prendere decisioni architetturali. Questo approccio integra l’analisi economica come un requisito non funzionale (NFR) primario, garantendo che la progettazione iniziale sia sostenibile e allineata all’obiettivo di massimizzare il valore del business a lungo termine. \u201cun’architettura ben progettata \u00e8 quella che bilancia performance, resilienza e costo nel tempo\u201d. <\/em><\/p>\n\n\n\n In altre parole, essere \u201cfrugali\u201d non significa spendere meno, ma spendere meglio costruendo sistemi che scalano in modo sostenibile senza compromessi sulla qualit\u00e0.<\/p>\n\n\n\n <\/p>\n\n\n <\/p>\n\n\n\n Chi fa il nostro mestiere sa che log e metriche sono fondamentali per comprendere lo stato di salute di un\u2019infrastruttura. Due delle soluzioni pi\u00f9 diffuse su AWS per la gestione centralizzata dei log sono Amazon CloudWatch Logs<\/strong> e Amazon OpenSearch Service<\/strong>. Entrambe offrono funzionalit\u00e0 robuste, ma la scelta tra l’una e l’altra dipende in larga misura dai requisiti specifici del caso d’uso, dal volume dei dati, dalla complessit\u00e0 delle query e dal budget a disposizione. La differenza cruciale risiede nel modello economico. L’approccio a consumo di CloudWatch pu\u00f2 far crescere rapidamente i costi con l’aumento del numero di metriche ad alta cardinalit\u00e0, della frequenza di campionamento e dei log ingeriti e conservati. Un cluster OpenSearch gestito, al contrario, introduce un costo pi\u00f9 “a gradini”: si dimensionano i nodi e si assorbe il volume, con un costo che scala in modo pi\u00f9 prevedibile. Superata una certa soglia di volume, spostare log ad alto volume e metriche personalizzate su OpenSearch (mantenendo in CloudWatch l’heartbeat e gli allarmi essenziali) risulta significativamente pi\u00f9 efficiente.<\/p>\n\n\n\n Nel seguente esempio \u00e8 stata considerata un\u2019applicazione di dimensione importante, basata su EC2 in autoscaling e con una media di diecimila utenti giornalieri che effettuano una media di un centinaio di chiamate a testa. Il singolo log record \u00e8 di dimensione abbastanza elevata: 4kB. Infine \u00e8 importante considerare che nell\u2019analisi sono state considerate istanze OpenSearch sovradimensionate, in modo da non avere problemi di risorse scarse e permettere operazioni di analisi dei dati.<\/p>\n\n\n\n <\/p>\n\n\n <\/p>\n\n\n\n Dal grafico si nota che per un numero limitato di macchine virtuali Cloudwatch rimane economicamente vantaggioso, ma quando le istanze sono in numero medio\/elevato il costo di OpenSearch raggiunge un plateau, mentre quello di Cloudwatch continua a salire linearmente. Un requisito non funzionale specifica i criteri che possono essere utilizzati per giudicare il funzionamento di un sistema (accessibilit\u00e0, disponibilit\u00e0, scalabilit\u00e0, …), ma ci\u00f2 che spesso viene trascurato \u00e8 il costo. I progetti possono fallire perch\u00e9 non si considerano i costi in ogni fase del business: dalla progettazione allo sviluppo fino all’operazione.<\/p>\n\n\n\n In ottica Frugal Architect<\/em>, questo significa introdurre la consapevolezza economica gi\u00e0 nella fase di design: ogni metrica raccolta, ogni retention policy e ogni log stream deve essere intenzionale. \u201cMeasure everything but pay attention to what you keep<\/strong>\u201d, direbbe Vogels.<\/p>\n\n\n\n Il vostro SaaS prende piede: clienti in aumento, richieste di isolamento dei dati e pressione sui costi operativi. La tentazione pu\u00f2 essere quella di dedicare un’installazione completa (Single tenancy) per ogni cliente, replicando load balancer, istanze EC2, database RDS, code di messaggistica e cos\u00ec via. Sebbene possa sembrare un approccio ordinato inizialmente, questo modello presenta criticit\u00e0: i costi crescono linearmente<\/strong> con ogni nuovo contratto, la complessit\u00e0 di gestione esplode (si moltiplicano gli upgrade e le patch) e i margini evaporano rapidamente.<\/p>\n\n\n\n <\/p>\n\n\n <\/p>\n\n\n\n Una multi-tenancy ben progettata consente di condividere in sicurezza risorse e infrastruttura, mantenendo isolamento logico tra i clienti.<\/p>\n\n\n\n Le opzioni principali sono:<\/p>\n\n\n\n La sicurezza rimane una priorit\u00e0 assoluta, ma la si ottiene attraverso l’isolamento logico<\/strong> (separazione dei dati tramite codice e configurazione), policy rigorose, crittografia per tenant e un’osservabilit\u00e0 avanzata per prevenire i “noisy neighbors” (clienti che influenzano negativamente le prestazioni di altri), anzich\u00e9 duplicando l’intera infrastruttura. <\/p>\n\n\n <\/p>\n\n\n\n I sistemi sostenibili allineano i costi alle curve di ricavo. In un’architettura multi-tenant, la crescita dei costi \u00e8 molto pi\u00f9 piatta; ogni cliente aggiuntivo porta con s\u00e9 marginalit\u00e0 positiva anzich\u00e9 la necessit\u00e0 di mantenere una nuova “mini-piattaforma” dedicata. Evitare la clonazione dell’infrastruttura non \u00e8 solo una questione di eleganza architetturale, ma \u00e8 ci\u00f2 che consente di scalare il business in modo sostenibile, senza far saltare il conto economico.<\/p>\n\n\n\n Gli anti-pattern che abbiamo esaminato hanno tutti un denominatore comune: nascono da decisioni prese considerando i costi come un problema “di dopo”, qualcosa da affrontare quando l’applicazione \u00e8 gi\u00e0 in produzione. Ma a quel punto \u00e8 troppo tardi: l’architettura \u00e8 definita e modificarla diventa costoso e rischioso.<\/p>\n\n\n\n La vera lezione del FinOps \u00e8 portare la consapevolezza nelle primissime fasi del ciclo di vita del software. Questo “shift-left” dei costi significa trattare l’impatto economico come un requisito alla pari di performance e sicurezza.<\/strong><\/p>\n\n\n\n Come ci ricorda The Frugal Architect: “Cost is a non-functional requirement”. E come ogni requisito non funzionale che si rispetti, va considerato fin dal primo giorno.<\/p>\n\n\n\n Sources:<\/em><\/p>\n\n\n\n
Beh, non proprio. O meglio, non solo.
Ridurre i costi \u00e8 certamente una parte del gioco, ma fermarsi qui sarebbe come pensare che DevOps significhi solo \u201cautomatizzare le build\u201d. In realt\u00e0, FinOps \u00e8 molto di pi\u00f9; \u00e8 un approccio culturale e operativo che unisce team tecnici, finanziari e di business per massimizzare il valore del Cloud<\/strong>, non semplicemente per risparmiare qualche dollaro.<\/p>\n\n\n\nCosa significa FinOps?<\/h2>\n\n\n\n
<\/figure><\/div>\n\n\n
Tre Anti-pattern comuni<\/h2>\n\n\n\n
Ma quanto \u00e8 bello il serverless?<\/h4>\n\n\n\n
<\/figure><\/div>\n\n\n
\n
\n
<\/figure><\/div>\n\n\n
Come ci ricorda anche Werner Vogels nel suo progetto The Frugal Architect, <\/p>\n\n\n\nLogging like no tomorrow<\/h4>\n\n\n\n
<\/figure><\/div>\n\n\n
Nativo, ben integrato e semplice da usare, quasi sempre Cloudwatch \u00e8 la scelta di default. In fase di kickoff di un progetto, il solo sentir parlare dei costi e della complessit\u00e0 di OpenSearch poi toglie qualunque dubbio. Purtroppo per\u00f2 anche questa volta la soluzione pi\u00f9 semplice non \u00e8 necessariamente la migliore, come sempre la soluzione migliore \u00e8: dipende<\/em>.<\/p>\n\n\n\n<\/figure><\/div>\n\n\n
<\/p>\n\n\n\nTenancy pi\u00f9 tenancy meno<\/h4>\n\n\n\n
<\/figure><\/div>\n\n\n
\n
Il diagramma di esempio questa volta \u00e8 molto semplice. Come detto in precedenza i costi con delle installazioni single-tenant aumentano linearmente con il numero delle installazioni. Pi\u00f9 difficile \u00e8 delineare i costi dell\u2019approccio multi-tenant, per questa analisi abbiamo considerato un incremento iniziale di circa il 50%, decrescente all\u2019aumentare dei clienti.<\/p>\n\n\n\n<\/figure><\/div>\n\n\n
Tirando le somme<\/h2>\n\n\n\n
\n\n\n\n