Ogni piattaforma cloud deve avere una qualche metrica del costo associata ai suoi servizi. Per la maggior parte delle offerte di cloud pubblico, le metriche target per il costo sono solitamente il numero di core CPU e la quantità di memoria. Questo viene moltiplicato per il tempo di utilizzo e si arriva a un prezzo basato sull’uso.
Questo modello ha i suoi pro e contro, quindi iteriamo un po’ su questo.
Poiché tutto il costo è legato a un modello di utilizzo, l’obiettivo è ridurre il costo riducendo l’utilizzo.
Il prezzo complessivo può essere in qualche modo stimato semplicemente sommando la quantità richiesta di CPU/Memoria nel tempo. Questo rende il pricing in qualche modo prevedibile (di più ne parleremo nella sezione dei Contro).
Le aziende che mirano alla prevedibilità del costo sceglieranno la soluzione che la garantisce. Quindi se voglio essere sicuro del costo, sceglierò il percorso meno flessibile e scalerò fino alla massima performance. Questo può sembrare controintuitivo (in termini economici), ma succede spesso nelle grandi organizzazioni dato che molte preferiscono la prevedibilità rispetto a qualche risparmio sui costi imprevedibile.
Tutti hanno un’idea di cosa sia una CPU/vCPU, ma in realtà non è una buona metrica per confrontare i provider. Devo sempre fare il mio benchmarking per vedere come i tipi di istanza, l’architettura CPU e lo scaling verticale influenzano le mie performance.
La potenza di elaborazione della CPU variabile rende anche molto difficile confrontare l’impatto reale, ad esempio l’impatto ambientale, per il mio progetto. Alcuni provider hanno già fatto passi avanti rendendo disponibili metriche CO2 (o equivalenti CO2), ma anche queste diventano molto complesse perché è difficile capire cosa è incluso e cosa escluso.
Quindi avere un prezzo basato sull’utilizzo è un grande passo avanti rispetto al pagare una quota mensile fissa senza che nessuno si preoccupi di cosa comporti. Cerca anche di dare un incentivo a ridurre l’impatto complessivo, ma offre comunque capacità limitate per confrontare i servizi tra provider.
Forse è tempo di portare il prezzo basato sull’utilizzo un passo oltre e cambiare la metrica.
Quindi se partiamo dal consumo di CPU e memoria nel tempo, possiamo catturare la quantità di risorse utilizzate a livello provider. Una metrica che ci manca qui, o che si potrebbe includere nel prezzo, è l’energia consumata (in watt).
Quindi invece di avere un costo calcolato dall’elaborazione, e un impatto ambientale calcolato tramite una metrica CO2, che ne diciamo di fondere i due e calcolare la potenza di elaborazione in watt? In questo modo possiamo fornire una metrica unica per costo e impatto.
Così, un’azienda che volesse migliorare la sua impronta ambientale migliorerebbe automaticamente il suo costo e viceversa. Entrambi gli obiettivi sarebbero visibili e azionabili.
Questo porta alla domanda di come dovrebbe funzionare, perché in teoria tutto suona semplice. In realtà c’è un grande problema: l’hardware attuale non fornisce questo tipo di metriche nella risoluzione di cui abbiamo bisogno.
Per ora dobbiamo stimare e lavorare intorno ai limiti del nostro hardware attuale.
Quello che abbiamo implementato finora è un misuratore di potenza su ogni macchina, così sappiamo la quantità totale di energia consumata (con risoluzione al minuto). Questa metrica viene sovrapposta al carico lavoro basato sull’utente su quelle macchine. Quello che otteniamo è una stima di quanta energia è stata consumata da quale utente. Vogliamo anche portare questa metrica nell’interfaccia utente il prima possibile.
Quindi questo è il nostro primo tentativo su questo argomento. Forniremo un altro aggiornamento se vedremo progressi in questa direzione o se incontreremo problemi che rendano questa idea non valida.
Per ora, sembra questa la strada giusta da percorrere.