I commitments sono un bersaglio mobile. I recommender nativi lo mancano, così abbiamo costruito il nostro.

Come il nostro motore trova il numero

In realtà i motori sono due. Uno per gli AWS Savings Plans, uno per i committed use discounts (CUD) di Google Cloud. Codice separato, perché i due cloud calcolano i prezzi e applicano i commitments in modi davvero diversi, e fingere il contrario sarebbe andato a scapito dell'accuratezza. L'idea di fondo, però, è la stessa.

Tutto inizia dai dati grezzi di utilizzo. Prendiamo ogni singola ora di spesa che un commitment potrebbe coprire nel periodo di lookback: per una finestra di 60 giorni, significa esaminare circa 1.440 singole ore con i loro importi esatti. Alcune di quelle ore saranno intensissime. Altre completamente vuote, soprattutto quando arriva il calo del weekend. Capire come gestire un andamento così altalenante è la vera sfida.

Poi togliamo ciò che già possiede. Se ha Savings Plans o CUD attivi, li applichiamo a ogni ora esattamente come fa il cloud provider, a partire dallo sconto migliore. Ciò che quei piani già coprono è fuori gioco. Ciò che resta è la spesa su cui un nuovo commitment può ancora farle risparmiare.

Teniamo conto anche di ogni sconto già in essere. Prezzi contrattuali negoziati. Sconti per utilizzo prolungato su Google Cloud. La copertura di Flexsave di DoiT, se lo utilizza. Un commitment ha senso solo se batte il prezzo che paga effettivamente oggi, quindi è con quello che facciamo il confronto, non con il prezzo di listino.

I due motori sono separati perché AWS e Google Cloud espongono i dati di fatturazione in modo diverso e applicano i commitments secondo le proprie regole. Il principio, però, è condiviso: valutare il commitment rispetto a ciò che paga davvero, non rispetto a un prezzo di listino che non vedrà mai in fattura.

Ora la parte che conta.

Prenda un qualsiasi commitment orario che potrebbe acquistare. Nella finestra pagherebbe due cose. Il commitment stesso, ogni singola ora, usato o meno. Più la spesa on-demand che eccede comunque nelle ore di punta. Sommandole si ottiene il costo totale a quel livello di commitment.

Un esempio rapido. Un'ora ha 100 $ di spesa idonea e Lei ha impegnato 30 $ l'ora con uno sconto del 40%, per semplicità. Quei 30 $ acquistano/coprono 50 $ di utilizzo on-demand. Quindi paga 30 $ per il commitment, 50 $ on-demand per il resto: 80 $ in totale invece di 100 $. Bene. Ora prenda un'ora tranquilla con solo 40 $ di spesa idonea. I suoi 30 $ comprano comunque 50 $ di copertura, solo che ce ne sono soltanto 40 da coprire. Paga 30 $, risparmia 10 $, e una fetta del commitment resta lì inutilizzata. Il recommender fa questi conti per ogni ora della finestra e somma tutto. Poi fa lo stesso per ogni livello di commitment che potrebbe consigliare, per vedere quale fa risparmiare di più.

Tracciando quel totale rispetto alla dimensione del commitment si ottiene una curva a conca. Il fondo della conca è il punto ideale: il commitment in cui il totale in fattura è più basso.

Sul lato sinistro si è sotto-impegnati. Ogni dollaro extra di commitment sostituisce più di un dollaro di spesa on-demand, quindi il costo totale scende. Sul lato destro si è sovra-impegnati. Il commitment in eccesso resta inutilizzato nelle ore tranquille, quindi il costo totale risale.

Il fondo della conca è il punto in cui un dollaro impegnato in più costerebbe più di quanto fa risparmiare. Quello è il commitment migliore. Non lo cerchiamo provando ogni valore centesimo per centesimo per poi tenere il più economico. La forma della curva ci dice dove si inverte, quindi andiamo dritti a quel punto.

Poi si sceglie una policy di rischio. Conservative, Balanced, Max Savings, o una definita da Lei. Ognuna prende una quota di quel commitment ottimale, 65%, 80% o 90%, lasciando margine per la settimana in cui l'utilizzo cala. Le policy personalizzate vanno oltre: fino a dieci per cliente, ciascuna con il proprio obiettivo di copertura e i propri step di acquisto, così la raccomandazione segue le sue regole anziché i tre preset pensati da un vendor cloud. Ho approfondito perché quel margine conta, e perché acquistiamo a step invece che tutto in una volta, in un post precedente sul problema del dimensionamento.

Sopra tutto questo c'è un piccolo set di leve di regolazione. Le tariamo man mano che gli acquisti reali ci insegnano qualcosa. Il loro compito è mantenere la raccomandazione sul lato prudente del valore ottimale di commitment.

Ad esempio, in alcuni casi il fondo della conca può sembrare piatto. Un intervallo di commitments, non un numero esatto, fa risparmiare quasi lo stesso importo. La matematica da sola punterebbe volentieri al più grande, ma noi no. Quando più dimensioni producono circa lo stesso risparmio, prendiamo la più piccola. Stesso risparmio, meno denaro vincolato, più margine se un workload scompare il mese prossimo.

Le leve ci permettono anche di reagire a ciò che vediamo in produzione. Se l'utilizzo di un account tende a calare nella finestra, la raccomandazione si orienta verso il basso. Se un acquisto si rivela meno utile di quanto previsto dal modello, ne facciamo tesoro e la raccomandazione successiva è più cauta.

E poiché il motore è nostro, quando un cliente chiede qualcosa di specifico, ad esempio "mai sotto il 70% di utilizzo" o "lasciate margine extra, stiamo consolidando gli account nel Q3", possiamo accontentarlo. Non si può chiedere ad AWS o a Google di eseguire il loro recommender con le proprie regole. Ma può chiederlo a noi, oppure creare la sua policy e noi la seguiremo.

Dove concordiamo con i cloud

Prima di parlare delle differenze, parliamo di fiducia. Se il nostro numero fosse lontano da quello del cloud, avrebbe ragione a chiedersi quale dei due sia sbagliato.

Così abbiamo verificato.

Una cosa deve essere corretta prima di tutto, altrimenti l'intero confronto è solo rumore: entrambi i recommender devono guardare gli stessi giorni di utilizzo. Ogni recommender dimensiona su una finestra di lookback, un intervallo fisso di ore passate. AWS consente di scegliere fino agli ultimi 60 giorni. Il nostro può essere impostato su qualsiasi valore. Se le due finestre non coincidono, anche solo di pochi giorni, i numeri differiranno, e quello scarto dipende soltanto dalle date, non dal metodo. Quindi per ogni confronto qui sotto abbiamo impostato il nostro motore sulle stesse identiche date di inizio e fine usate da AWS o da Google. Stessi giorni in ingresso, poi si confronta ciò che esce.

Su AWS, abbiamo confrontato il nostro motore con l'AWS Purchase Analyzer su più account. Abbiamo testato ogni combinazione: durate di uno e tre anni, no upfront, partial upfront e all upfront. Stessa finestra di lookback da entrambe le parti. Il commitment raccomandato dal nostro motore è risultato entro l'1% del numero di AWS in ogni caso. Abbiamo anche eseguito il motore sul nostro cliente AWS più grande per assicurarci che regga su larga scala. Regge.

Su Google Cloud, abbiamo confrontato con le raccomandazioni mostrate nella console GCP. Su un billing account con prezzi standard, abbiamo eguagliato Google al centesimo, in tutti e otto gli ambiti di commitment testati. Inclusi i CUD Compute Flexible, Memorystore e Cloud SQL in ogni regione. Su un account con sconti negoziati, siamo stati entro l'1%.

Cloud	Tipo di account	Ambiti testati	Il nostro numero vs quello del cloud
AWS	Payer di medie dimensioni, tutte le combinazioni di durata e pagamento	6	Entro l'1%
AWS	Il nostro cliente più grande	6	Funziona senza problemi, entro l'1%
Google Cloud	Prezzi standard	8	Corrispondenza esatta, al centesimo
Google Cloud	Sconti negoziati	8	Entro l'1%

Il punto è semplice. Facendo la stessa domanda, si ottiene la stessa risposta. Nessuno si inventa un numero più grande per venderle di più.

Allora perché costruirne uno nostro?

Dove i cloud si fermano e noi andiamo avanti

Ecco le domande che i nostri clienti ci pongono davvero. In ciascun caso, il recommender del cloud non sa rispondere, oppure la fa aspettare. La versione breve, prima dei dettagli:

	AWS	Google Cloud	DoiT
Accuratezza della raccomandazione	Baseline	Baseline	Entro l'1% da entrambi
Ogni opzione di durata e pagamento, on demand	20 analisi al giorno, una alla volta	Solo alcuni scenari	Tutte le combinazioni in meno di 20 secondi
API sincrona	Job asincrono, polling di minuti	Non disponibile	Sì
Spiegare perché il numero è cambiato	No	No	Sì, fino alle righe di fatturazione
Delimitazione per account o SKU	No	No	Sì
Intervallo di date personalizzato	Parziale	Parziale	Sì
Indipendente dall'API del cloud il giorno dell'acquisto	No	No	Sì, legge direttamente i dati di fatturazione
Scala di acquisti automatizzata	No	No	Sì
Commitments in scadenza	Nuova raccomandazione dopo la scadenza	Nuova raccomandazione dopo la scadenza	Sostituzione dimensionata e pianificata prima della scadenza
Monitoraggio umano dell'utilizzo	No	No	Sì, team DoiT dedicato

"Voglio confrontare 1 anno vs 3 anni, no upfront vs all upfront, e tre livelli di rischio, prima di decidere."

Su AWS, ognuna di queste è un'analisi separata. Il Purchase Analyzer consente 20 analisi per payer account al giorno. Ognuna richiede da qualche secondo a qualche minuto, e vengono eseguite una alla volta. Per vedere il quadro completo di un payer servono più analisi di quante AWS ne consenta in un giorno. Quindi ne sceglie alcune, aspetta e spera di aver scelto bene.

Google Cloud qui è più flessibile. La console permette di costruire scenari su diversi periodi di lookback, e si può escludere un insieme di date. Utile. Ma si ferma lì. Si ottengono le opzioni a cui Google ha pensato, alle condizioni di Google, e appena si vuole qualcosa fuori da quella lista si è da soli.

Il nostro motore produce ogni combinazione per un payer account in meno di 20 secondi. Può eseguirlo tutte le volte che vuole.

"Voglio integrare le raccomandazioni nei miei strumenti."

Il recommender di AWS è un job asincrono. Lo si avvia, poi si fa polling finché non termina, secondi o minuti dopo. Costruirci sopra una pipeline affidabile richiede lavoro, e il limite giornaliero resta.

La raccomandazione della console Google Cloud è pensata per essere letta, non per alimentare un workflow di acquisto.

La nostra è una REST API sincrona, parte della DoiT Cloud Intelligence API. Chiama l'endpoint con la sua API key e riceve la raccomandazione nella stessa risposta. Ha la stessa struttura su AWS e Google Cloud, quindi una sola integrazione copre entrambi. Può pubblicare la raccomandazione giornaliera su Slack, aprire un ticket quando si sposta oltre una certa soglia, o portarla nella sua dashboard FinOps accanto al resto dei suoi dati di costo.

E poiché è una semplice API sincrona, si collega a un assistente AI con la stessa facilità di una dashboard. La colleghi a Claude, o a quello che usa, e chieda a parole: "Qual è la raccomandazione per Cloud SQL in us-east1?" "Quando scade il mio prossimo commitment?" "Quanto ci hanno fatto risparmiare i commitments sul compute il mese scorso?" Provi a chiederlo a una console.

Tutto, inoltre, è calcolato in anticipo. Ogni opzione, ogni policy, ogni account, una volta al giorno. Così, quando la domanda arriva, da Lei o dal suo assistente, nulla finisce in coda, nulla è soggetto a rate limit e non c'è attesa per singola opzione. La risposta è già lì.

"Perché il numero è cambiato rispetto alla settimana scorsa?"

Abbiamo visto la raccomandazione di un payer AWS oscillare tra due livelli piuttosto diversi nell'arco di una sola settimana. Nulla nell'utilizzo lo spiegava. La nostra lettura più plausibile è che dipenda dalla finestra mobile e dal giorno della settimana in cui si chiede. Ma non possiamo esserne certi, perché il Purchase Analyzer non mostra il proprio procedimento in modo abbastanza chiaro da poterlo verificare.

Ogni numero prodotto dal nostro motore è riconducibile alle righe di fatturazione. Quando un cliente chiede perché la raccomandazione si è spostata, possiamo mostrargli quali ore sono cambiate e di quanto. Spesso la risposta è semplice: un job batch ha smesso di girare di notte, o un nuovo ambiente è andato online giovedì. In ogni caso, ottiene una risposta invece di un'alzata di spalle.

"Quell'account è in dismissione. Ignoratelo."

Oppure: "Escludete questi SKU, stiamo spostando quel workload." Oppure: "Dimensionatelo sull'ultimo trimestre, non sulla finestra predefinita."

Nessuno dei due cloud permette di delimitare la raccomandazione per account, per SKU o per un periodo di tempo esplicito. Si ottiene una risposta per l'intero payer, sulla finestra scelta da loro.

Il nostro permette tutte e tre le cose. Escludere un account. Rimuovere una quota di SKU specifici. Impostare le proprie date di inizio e fine. Anche l'idoneità è granulare: quali linked account o progetti rientrano nell'ambito dei commitments è un'impostazione, e il motore dimensiona solo su quelli. Oggi la configuriamo noi per Lei; un controllo self-service è in arrivo. E dietro ci sono più controlli di quanti ne esponga una qualsiasi delle due console.

Una precisazione, per onestà: oggi questi non sono pulsanti self-service nella console. Le basta comunicare al suo team DoiT cosa escludere o quali date usare, e noi eseguiamo il motore con quelle impostazioni per Lei. Il punto è che si può fare, e che la risposta arriva in giornata. E tutto questo è nei nostri piani: intendiamo mettere queste leve nelle mani dei clienti, così che possano controllare ogni aspetto in autonomia.

"E se Cost Explorer non è disponibile il giorno dell'acquisto?"

Sembra un caso limite finché non succede. Dimensionare un commitment non è un lavoro una tantum. Come ho sostenuto nel post sul dimensionamento, è un bersaglio mobile che bisogna continuare a centrare, settimana dopo settimana, mentre l'utilizzo cambia sotto i piedi. E il bersaglio si moltiplica. Due cloud, compute più database, diverse regioni, ognuna con il proprio commitment e la propria data di scadenza. Non è una decisione settimanale. È una dozzina.

Un recommender che dipende da un job esterno può perdere un passaggio. Se l'API è lenta, soggetta a rate limit o nel bel mezzo di un incidente, l'acquisto di quella settimana non avviene. Il nostro legge direttamente i suoi dati di fatturazione. Non c'è nulla di esterno da aspettare.

"Non voglio fare da babysitter a questa cosa."

Ecco il punto. Questa è la vera risposta a "perché dovrei aver bisogno del vostro".

Una raccomandazione è utile solo se qualcuno agisce di conseguenza. Il nostro motore alimenta una scala di acquisti automatizzata. Gli acquisti avvengono dietro le quinte, con una cadenza controllata dal cliente, in step dimensionati dalla policy scelta. E un team DoiT dedicato monitora l'utilizzo di ogni commitment. Se qualcosa inizia a restare inutilizzato, lo intercetta prima che diventi spreco in fattura. Su AWS questo può persino significare restituire un Savings Plan finché la finestra di restituzione è ancora aperta.

Le scadenze sono gestite allo stesso modo. Quando un piano sta per esaurirsi, la raccomandazione successiva presume già che non ci sia più, e la scala pianifica la sostituzione in modo che parta nel momento esatto in cui il vecchio termina. La copertura non crolla per una settimana in attesa che qualcuno se ne accorga. I recommender dei cloud vedono il buco solo dopo che si è aperto.

Presto i clienti potranno definire da sé anche la policy di cadenza degli acquisti, oltre alla policy di rischio che già scelgono oggi.