Introduzione
Quando la spesa cloud cresce e si fa più complessa, suddividere la fattura solo per servizio o per progetto/account non basta più, se vuole capire davvero come si distribuiscono i costi nella sua organizzazione.
L'obiettivo è organizzare i costi in modo coerente con il funzionamento del suo business. Potrebbe avere più team, più ambienti o altre categorie a cui imputare la spesa. Ma queste categorie possono avere definizioni tutt'altro che banali: ad esempio, lo "Staging Environment" della sua azienda potrebbe comprendere tutti i progetti o gli account il cui nome inizia con "staging", trasversalmente a più team o servizi.
Con le Allocations di DoiT Cloud Intelligence, può mappare i costi cloud su categorie di business personalizzate, raggruppandoli su più dimensioni: Label/Tag, progetti, account, tipi di servizio, regioni o persino metadati di fatturazione. Le Allocations supportano sia strategie di costo dirette sia condivise, comprese regole automatizzate per ripartire proporzionalmente servizi trasversali come supporto o networking.
Vediamo cosa sono le Allocations e come funzionano. Se preferisce, può saltare direttamente al tour interattivo.
Cosa sono le Allocations?
Un'Allocation è un raggruppamento logico di risorse cloud che definisce una categoria di costo specifica per la sua organizzazione.
Le aziende usano le Allocations nella DoiT Platform per leggere il consumo cloud nel contesto del proprio business.
Sono inoltre un passo fondamentale per introdurre la responsabilizzazione sui costi tra team e funzioni aziendali.
Vediamo qualche esempio concreto di come funzionano:
Definire i costi dei team di engineering
In DoiT usiamo le Allocations al nostro interno per definire l'impronta cloud di ciascun team di engineering. In questo esempio abbiamo creato un'Allocation per il team Bruteforce, raggruppando le risorse in cui una label a livello di risorsa o una label a livello di progetto è uguale a "bruteforce".
Applichiamo una logica "A OR B" per assicurarci che l'Allocation includa le risorse che sono:
- Etichettate solo con la label di risorsa team:bruteforce
- Etichettate solo con la label di progetto team:bruteforce
- Etichettate con entrambe
Così otteniamo una copertura completa dei costi di Bruteforce, indipendentemente da dove la label sia stata applicata.
Screenshot
Molti clienti usano le Allocations in questo modo per alimentare dashboard e report dedicati a ciascun team, che mettono in evidenza le principali voci di spesa.
Nell'esempio qui sotto scomponiamo i costi di Bruteforce per servizio: in un colpo d'occhio si vede cosa sta guidando la spesa di quel team di engineering.
Screenshot
Definire i costi degli ambienti
In questo esempio definiamo i costi del nostro Staging Environment raggruppando, tramite regex, tutti i progetti Google Cloud il cui nome contiene la parola "staging".
È un buon esempio di come si possano costruire Allocations senza dover passare da label o tag.
Screenshot
Poiché i progetti di staging vengono spesso creati o eliminati nel tempo, l'uso delle regex fa sì che l'Allocation resti aggiornata in automatico, senza doverla rivedere manualmente ogni volta che si aggiunge un nuovo progetto.
Screenshot
Nell'esempio qui sotto abbiamo creato un report Cost per Environment che mette a confronto tre Allocations: Development, Staging e Production. Così possiamo monitorare l'utilizzo per ambiente e confrontare i trend nel tempo.
Screenshot
Possiamo anche scomporre i costi di ciascun ambiente per servizio, account o regione, per capire da dove arrivano le differenze.
Screenshot
Infine, può programmare l'aggiornamento automatico di questi report e l'invio agli stakeholder chiave con la cadenza che preferisce, così tutti restano allineati.
Screenshot
Stimare i risparmi sullo storage EBS
Le Allocations non si limitano a categorie organizzative o di team: può usarle anche per raggruppare componenti infrastrutturali a fini di analisi e modellazione di scenari.
Supponiamo, ad esempio, che stia utilizzando volumi GP2 per AWS EBS e voglia stimare il risparmio potenziale di una migrazione a GP3.
Inizi creando un'Allocation che intercetti tutti i costi EBS legati ai volumi GP2. Lo si può fare filtrando i metadati di servizio AWS pertinenti — tipo di volume, tipo di utilizzo o SKU — che identificano l'uso di GP2:
Screenshot
Una volta definita l'Allocation, può abbinarla alle Metrics della DoiT Platform per costruire il suo modello di risparmio.
Secondo AWS, i volumi GP3 hanno un prezzo per GB fino al 20% inferiore rispetto ai GP2. Per stimare il risparmio potenziale, crei una metrica personalizzata che moltiplichi il costo dell'Allocation GP2 per 0,2.
Screenshot
In alternativa, per stimare il costo rettificato nell'ipotesi di essere già su GP3, moltiplichi la stessa Allocation per 0,8.
Ottiene così, in pochi passaggi e in self-service, un modo per:
- Quantificare il risparmio potenziale giornaliero
- Stabilire le priorità degli interventi di migrazione dello storage
- Validare le decisioni architetturali con dati di costo reali
Altri modi per usare le Allocations
Una volta definite, le Allocations diventano input preziosi in tutta la DoiT Platform e abilitano insight più precisi, concreti e calati sul business.
Abbiamo già visto come aiutino a costruire report di costo più significativi, ma la loro utilità va ben oltre. I clienti DoiT le usano anche per:
- Allocare la spesa con precisione
- Mappare ogni dollaro di costo cloud su una specifica unità di business, prodotto o iniziativa, colmando le lacune dovute a tag incoerenti o a strutture di fatturazione frammentate
- Migliorare l'accuratezza di forecast ed enforcement con i Budgets
- Imposti budget circoscritti alle Allocation per capire se un team, un ambiente o un'applicazione sta superando le previsioni e avvisare in modo proattivo i responsabili.
- Creare alert granulari e mirati
- Far emergere anomalie, picchi di costo o variazioni d'uso a livello di Allocation, e non solo di account o servizio, perché chi deve intervenire possa farlo subito.
- Favorire un dialogo più efficace tra team
- Poiché le allocazioni rispecchiano la struttura della sua azienda, diventano un linguaggio comune con cui Finance, Engineering e Leadership possono valutare l'andamento dei costi e prendere decisioni.
- E molto altro!
Può approfondire gli altri casi d'uso in questo articolo.
E i Tag e le Label?
Forse, leggendo, sta pensando: "Ma non posso ottenere lo stesso risultato con tag e label?". Le Allocations sostituiscono tag e label?
Sono due concetti distinti, anche se in parte si sovrappongono. Le Allocations le permettono di organizzare la spesa cloud senza pretendere un tagging perfetto. Può senz'altro usare tag e label come input per costruirle, ma non è obbligato a farlo.
Sì, può ottenere raggruppamenti analoghi usando solo tag e label, a patto che la sua organizzazione abbia una rigorosa igiene di tagging. Ovvero:
- Una sola chiave di tag coerente per ciascuna categoria (ad es. environment, product, team)
- Un set definito di valori per ogni chiave (ad es. prod, dev, staging)
- Copertura del 100% dei tag su tutte le risorse
Ecco come potrebbe apparire un report in AWS Cost Explorer con tag AWS applicati in modo corretto e coerente:
Chiavi e/o valori dei Tag duplicati
Nella realtà, però, molte organizzazioni convivono con un tagging frammentato. Può capitare di avere chiavi incoerenti come Environment, Env o environment, e valori come prod, production o Production.
Questa incoerenza rende più difficile il reporting dei costi, perché in modo nativo non si possono raggruppare quei valori in un'unica unità logica.
Con le Allocations può definire un singolo raggruppamento allineato al business (ad es. "Production Environment") che racchiuda tutte queste varianti di tag in un'unica regola.
Qui sotto abbiamo riunito in un'unica Allocation le risorse con valori del tag Environment pari a prod, Production e production:
Screenshot
Multi-cloud
Immaginiamo che la sua applicazione giri sia su AWS sia su Google Cloud. Come ne misura il costo complessivo?
Nativamente non è possibile farlo dalla console di nessuno dei due provider: ognuna vede solo i propri dati.
Con le Allocations nella DoiT Platform può raggruppare le risorse di entrambi i cloud sfruttando metadati condivisi come tag, label, ID account, nomi di progetto e altro ancora. Ottiene così una visione unificata dei costi di qualsiasi servizio o prodotto multi-cloud.
Tag inadatti al raggruppamento di costo che vuole costruire
A volte i tag, semplicemente, non sono lo strumento giusto per il raggruppamento che ha in mente.
Potrebbe ad esempio voler definire i costi dello "Staging Environment" aggregando gli account AWS o i progetti GCP il cui nome contiene "staging", a prescindere dal fatto che quelle risorse siano taggate o meno.
Con le Allocations può sfruttare nomi di progetto/account, match con regex e altre dimensioni per costruire questi raggruppamenti di costo.
Screenshot
Sistemi legacy che non si prestano al tagging
Alcuni clienti hanno sistemi legacy che non supportano i tag o non consentono di far rispettare standard di tagging.
In questi casi, nelle console native non c'è una soluzione efficace. Con le Allocations, invece, può raggruppare le risorse non taggate sulla base di altri metadati, come ID account, regione, nome del servizio o logiche personalizzate.
Conclusione
Sia che voglia leggere la spesa cloud nel contesto del suo business, sia che voglia diffondere la responsabilizzazione sui costi tra i team, il punto di partenza sono le Allocations.
Pronto a ottenere un quadro più chiaro dei suoi costi cloud? Provi il tour interattivo qui sotto, oppure contatti DoiT per fissare una demo personalizzata e scoprire come le Allocations e il resto della DoiT Platform possono lavorare per il suo team.
Faccia un tour interattivo delle Allocations