I tre pilastri per costruire una cultura di ottimizzazione dei costi in azienda — con una guida passo passo basata sui prodotti DoiT.
In molte aziende l'ottimizzazione dei costi è una reazione di emergenza, innescata da un fattore esterno: il team finance che riceve una fattura inaspettatamente salata o la necessità di ridurre il burn rate in vista di un round di finanziamento.
Se la Sua azienda si riconosce in questo scenario, è il momento di adottare un approccio più proattivo a tutti i livelli. L'ottimizzazione dei costi non può essere compito di una sola persona: ogni engineer e ogni utente cloud deve sentirla come propria.
Per ottenere questo risultato occorre però diffondere il senso di responsabilità e di ownership dei costi cloud tra tutti gli utenti. È possibile solo se ciascuno è consapevole dei costi che genera. E ciò richiede una corretta cost allocation, ovvero la mappatura dei costi cloud ai rispettivi responsabili.
YouTube
Tocca per riattivare l'audio
Errore 153
Errore di configurazione del player video
Vai su YouTube per cercare altri video
Quando gli utenti cloud conoscono i propri costi, iniziano a interessarsene davvero. Pongono domande più mirate sul perché la spesa abbia un certo valore. E sono in grado di agire in anticipo, integrando il fattore costo già nella progettazione delle funzionalità o intervenendo per tempo sulle voci di spesa in lenta crescita.
Vediamo i tre pilastri per costruire una cultura attenta ai costi nella Sua azienda, in modo che diventi una pratica costante per tutti gli utenti cloud.
Consiglio #1 - Allinei la gerarchia delle risorse alla struttura organizzativa
Idealmente, le risorse cloud andrebbero organizzate rispecchiando la reale struttura aziendale: i Folders di Google Cloud o le Organizational Units (OU) di AWS sono lo strumento ideale per farlo.
Servono a separare e categorizzare le risorse dei diversi reparti o team all'interno dell'organizzazione. Al loro interno si trovano i progetti (Google Cloud) o gli account (AWS), in cui ciascun workload appartiene a un singolo progetto/account.
YouTube
Tocca per riattivare l'audio
Errore 153
Errore di configurazione del player video
Vai su YouTube per cercare altri video
Senza questa struttura, è facile imbattersi in problemi come la proliferazione delle risorse, le difficoltà di attribuzione dei costi e la complessità nella gestione degli accessi.
Non è un concetto nuovo nel mondo dello sviluppo software. La Legge di Conway sostiene che il modo in cui i team comunicano e si organizzano influenza i prodotti o i sistemi che realizzano. Allo stesso modo, nel cloud computing, una struttura delle risorse che riflette quella dell'azienda rende gestione e collaborazione molto più fluide.
Isoli i workloads in account o progetti dedicati
È inoltre fondamentale isolare i workloads in account AWS o progetti Google Cloud dedicati. Capita spesso di incontrare clienti con tutti i workloads in un unico account/progetto, oppure che condividono progetti o account tra più team.
Quando si raggruppano workloads non correlati nello stesso account o progetto, gestire i costi e tracciarne l'utilizzo diventa un'impresa.
YouTube
Tocca per riattivare l'audio
Errore 153
Errore di configurazione del player video
Vai su YouTube per cercare altri video
Si pensi, ad esempio, a risorse appartenenti a due applicazioni diverse all'interno dello stesso progetto Google Cloud. Non isolando le risorse in progetti o account distinti, si finisce per dipendere in modo eccessivo da un'igiene di tagging impeccabile (ne parleremo nel prossimo consiglio). E man mano che l'organizzazione cresce, questo approccio non fa che complicare l'attribuzione dei costi.
Quando possibile, è preferibile mantenere un singolo workload per account o progetto. Tuttavia, in presenza di workloads di piccole dimensioni e portata simile, può avere senso raccoglierli nello stesso account (vedere l'illustrazione sotto).
Anche in questo caso, l'idea non è nuova per chi ha familiarità con la programmazione. Isolare i workloads cloud in account o progetti separati richiama il principio del "loose coupling", ovvero la progettazione di componenti o moduli indipendenti, che interagiscono tra loro con il minimo di dipendenze.
Separando i workloads in account o progetti distinti, si creano ambienti indipendenti con dipendenze reciproche minime. I vantaggi vanno ben oltre la sola cost allocation: si beneficia anche di funzionalità di sicurezza operativa integrate, come strutture di permessi e rate-limiting, proprio grazie alla separazione dei workloads.
Consiglio #2 - Applichi tag e/o label alle risorse
I Tag (AWS, Azure) e le Label (Google Cloud) servono ad arricchire le risorse cloud con informazioni di dettaglio.
Tra i casi d'uso più comuni:
- Arricchimento del billing (es. associare il cost center a una risorsa)
- Classificazione di ambiente o applicazione (es. specificare i livelli di sicurezza dei dati)
- Automazione (es. definire i programmi di riavvio)
Concentriamoci sul primo: tag e label svolgono un ruolo cruciale nella cost allocation e nel tracciamento della spesa.
I tag aiutano a categorizzare le risorse per ambiente, team e altri criteri, fornendo una chiara distinzione del consumo nelle categorie definite. Combinati con account ben strutturati, i tag rendono più semplice personalizzare la reportistica per team, applicazioni e altro ancora, grazie a filtri più mirati.
YouTube
Tocca per riattivare l'audio
Errore 153
Errore di configurazione del player video
Vai su YouTube per cercare altri video
Regole d'oro per il tagging delle risorse cloud
Quando si parla di tagging, la tentazione è quella di definire una struttura iper-dettagliata, con decine di tag da applicare a ogni risorsa. Per quanto ammirevole, è un approccio poco realistico in fase di avvio. Consigliamo di partire in piccolo, con soli 2-3 tag, ma applicandoli con assoluto rigore.
I tre tag che riteniamo davvero indispensabili sono:
- Nome dell'applicazione (es. "app_name")
- Team (es. "team")
- Stage/ambiente (es. "env")
Poiché i tag sono case sensitive, raccomandiamo di adottare una convenzione di denominazione, come lo snake case, per evitare duplicazioni. I nomi possono naturalmente essere adattati alla cultura aziendale, purché rimangano descrittivi e chiari. In questo caso "app_name" indica un microservizio o il nome di un workload, mentre "env" identifica una fase di sviluppo come "development", "testing" o "production".
I valori di entrambi i campi dovrebbero idealmente provenire da un elenco abbastanza standardizzato. Anche qui vale la regola: se gli utenti taggano le risorse con varianti di "Website - Backend", l'analisi dei dati rischia di diventare un rebus.
Un caso tipico in cui i tag aiutano a capire meglio il consumo cloud è quello dell'account di "risorse condivise" all'interno di un'organizzazione, in cui sono concentrate tutte le risorse di database utilizzate da più team. A ciascun database si può assegnare un tag o una label che indichi quale team debba sostenere il costo di quella risorsa.
Approfondiamo l'argomento nel nostro articolo Resource Labeling Best Practices.
Consiglio #3 - Imposti reportistica in tempo reale e alert personalizzati
Definire una gerarchia di risorse cloud ben organizzata e taggare ogni risorsa è importante, ma se poi non si forniscono agli utenti cloud reportistica e alert in tempo reale su questi dati segmentati, tutto lo sforzo rischia di essere vano.
L'"Effetto Prius"
In "Cloud FinOps" di O'Reilly, gli autori spiegano l'"Effetto Prius", tracciando un parallelo tra l'impatto della reportistica in tempo reale sui comportamenti cost-conscious degli engineer e la guida di una Prius.
Quando si guida una Prius, si ricevono informazioni in tempo reale sul consumo energetico e sull'autonomia residua della batteria. Premendo a fondo l'acceleratore si vede crescere il consumo e ridursi rapidamente l'autonomia. Questa informazione può portare a uno stile di guida più ragionevole. Oppure si può decidere che, vista la fretta, valga la pena accelerare anche a costo di scaricare la batteria più in fretta.
Qualunque sia la scelta, il punto è che ora la si compie in modo informato, grazie a dati che prima non erano disponibili.
La reportistica in tempo reale abilita decisioni decentralizzate e consapevoli
La reportistica in tempo reale dei costi cloud, come la Prius che mostra l'impatto del consumo sull'autonomia, fornisce insight immediati e mette gli utenti cloud in condizione di decidere in autonomia, in modo informato, sulle parti di infrastruttura di cui sono responsabili.
E sebbene la transizione verso una mentalità più attenta ai costi non avvenga dall'oggi al domani, la reportistica in tempo reale orienta progressivamente i comportamenti verso decisioni più efficienti dal punto di vista economico.
Deve assumere la forma di report su costi e utilizzo, dashboard, budget e alert personalizzati che forniscano informazioni rilevanti per chi le consulta. In altre parole, ogni report visualizzato da un utente cloud dovrebbe essere filtrato (combinando opportunamente i tag e gli account pertinenti) per mostrare esclusivamente il consumo di cui lui o il suo team sono responsabili.
Promuovere una cultura attenta ai costi con DoiT
Le organizzazioni digital native si affidano al portafoglio di prodotti DoiT — e alla rete globale di competenze cloud per FinOps e supporto infrastrutturale — per prendere decisioni informate sull'uso del cloud.
Ecco una guida passo passo che mostra come molti clienti DoiT diffondono una cultura di consapevolezza e responsabilità sui costi nei loro team di engineering.
Mappi i costi cloud sulle Sue categorie di business
Il primo passo della cost allocation consiste nel definire i raggruppamenti di business a cui imputare i costi. In DoiT Cloud Intelligence™ ciò avviene tramite le Attributions, che permettono di raggruppare le risorse cloud e organizzare i costi secondo il modello di allocazione desiderato.
Vediamo due esempi di utilizzo delle Attributions per mappare i costi su diverse categorie di business.
Nel primo, definiamo i costi di un'applicazione raggruppando tre diversi account AWS.
Mappatura dei costi cloud per un'applicazione ipotetica
Nel secondo, definiamo i costi di un team di product engineering (in questo caso "Team Bruteforce") come qualsiasi risorsa con una Label "team" o un valore di Project Label pari a "bruteforce".
Mappatura dei costi cloud per un team di engineering ipotetico
Crei reportistica e dashboard in tempo reale
Può poi utilizzare le Attributions nei Report — e successivamente nelle Dashboard — per filtrare il consumo specifico di un team, di un ambiente, di un'app o di qualsiasi altra entità Lei abbia definito tramite Attributions.
Qui sotto, ad esempio, abbiamo usato l'Attribution "Application A" come filtro, suddividendo i costi per servizio e mostrando solo le 10 voci di spesa principali.
Un report sui costi cloud che dettaglia le spese di un'applicazione definita tramite DoiT Attributions
Può quindi pianificare l'aggiornamento e l'invio ricorrente del report agli utenti cloud per cui è rilevante. È un modo semplice per iniziare a rendere le persone più consapevoli del proprio impatto sui costi cloud.
Pianificazione dell'invio ricorrente di un report sui costi cloud
Può inoltre creare una dashboard dedicata a un team o a un'app, offrendo agli utenti cloud interessati una visione complessiva dei propri costi. Qui sotto abbiamo aggiunto il report "Application A - Service Cost" a una nuova dashboard, destinata a raccogliere altri report relativi al consumo di questa applicazione.
Aggiunta di un report sui costi cloud di un'applicazione a una dashboard contenente altri report sulla stessa applicazione.
La dashboard qui sotto è un esempio di ciò che può creare per il Suo team, oltre alla pianificazione di report mirati per gli utenti cloud interessati.
Dashboard con report personalizzati sui costi cloud di una specifica applicazione
Alert personalizzati e Anomaly Detection mirata
Oltre ai report, alert tempestivi che segnalino agli utenti quando approfondire un determinato aspetto della spesa cloud possono contribuire ad aumentare consapevolezza e responsabilità.
Imposti alert granulari sui costi cloud per gli stakeholder
I clienti DoiT, ad esempio, configurano gli Alert quando vogliono che gli stakeholder abbiano visibilità sull'utilizzo a livelli più granulari.
Qui sotto abbiamo impostato un alert sui costi limitato all'Attribution "Application A". Per come è configurato, riceveremo una notifica ogni volta che il costo per servire un qualsiasi customer — definito selezionando il tag "customer" nel menu a tendina Evaluate for each — aumenta del 25% o più, settimana su settimana. Il menu Evaluate for each è particolarmente utile quando si vuole valutare separatamente ogni istanza della stessa dimensione (ad esempio ciascuno dei propri namespace K8s).
Un alert che ci notifica ogni volta che il costo per servire un customer — definito selezionando il tag "customer" nel menu a tendina Evaluate for each — aumenta del 25% o più, settimana su settimana
Imposti un'Anomaly Detection mirata
DoiT Anomaly Detection monitora autonomamente i picchi di costo e segnala spese anomale per minimizzarne l'impatto sulla fattura. Per impostazione predefinita, individua comportamenti anomali per ciascuno SKU su ogni account o progetto presente.
Esempio di anomalia rilevata sullo SKU DataTransfer-Out-Bytes di AWS S3
I sistemi di anomaly detection forniscono in genere insight sull'uso cloud dell'intera organizzazione. Tuttavia, questo approccio così esteso finisce spesso per inondare i team di notifiche poco pertinenti rispetto alle loro attività.
Con DoiT Anomaly Detection, invece, è possibile iscrivere gli utenti cloud agli alert relativi ai soli costi di cui sono responsabili, sfruttando le Attributions. Si porta così l'alerting sulle anomalie a un livello superiore, consentendo ai team di affinare le notifiche concentrandosi unicamente sui costi cloud che li riguardano.
Una volta creata un'Attribution, basta attivare l'Anomaly Detection per quella specifica voce.
Attivazione dell'Anomaly Detection per le risorse cloud di una specifica applicazione
Successivamente, può accedere alle impostazioni di notifica delle persone responsabili di Application A e iscriverle agli alert relativi a quell'Attribution (o lasciare che lo facciano in autonomia).
Come iscriversi agli alert sulle anomalie per una specifica Attribution
Costruire una cultura attenta ai costi in tutta l'azienda non è semplice come dire agli utenti cloud di iniziare a preoccuparsene di più. Occorre fornire loro i dati che li rendano consapevoli dell'impatto economico del proprio lavoro.
E per offrire dati il più possibile precisi sull'impatto di ciascuna persona o team sulla fattura cloud, è necessario allineare la gerarchia delle risorse alla struttura organizzativa, definire i tag adeguati e applicarli sistematicamente. Il vero valore, però, emerge quando questi passaggi fondamentali vengono affiancati a meccanismi di reportistica e alert in tempo reale.
Con DoiT può ottenere entrambi: parta da una collaborazione con i nostri esperti FinOps per definire i tag da creare — se non lo ha già fatto — e una gerarchia di risorse coerente con la struttura della Sua azienda.
Una volta gettate queste basi, può utilizzare i prodotti DoiT per recapitare reportistica e alert pertinenti e in tempo reale ai Suoi utenti cloud.
Se è già cliente DoiT, può seguire passo passo quanto descritto sopra direttamente in DoiT Cloud Intelligence. In caso contrario, ci contatti per scoprire come sfruttare i prodotti e i servizi di consulenza DoiT in qualunque fase del Suo percorso cloud.