Introduzione
Oggi giorno è possibile determinare il costo del cloud, attraverso strumenti specifici di analisi offerti dai vari hyperscaler presenti sul mercato o proposti da terze parti.
E’ più complesso determinare il Total Cost of Ownership, acronimo TCO, di una applicazione in cloud o di un intero ecosistema informativo cloud native
In questo articolo provo a fornire una chiave di interpretazione assieme a qualche strumento da utilizzare per determinare il reale costo di gestione di una risorsa cloud in base al suo modello di servizio.
Classificare le risorse cloud in base ai loro modelli di servizio aiuta a determinare il migliore approccio in una fase di adozione del cloud o in un suo consolidamento.
Il calcolo del TCO richiede una comprensione su cosa sia il modello di servizio di una risorsa in cloud e quali sia vantaggi e svantaggi nell’impiego di un modello di servizio rispetto ad un altro.
Modelli di servizio di una risorsa cloud
L’articolo Modelli di servizio di una risorsa cloud presenta i modelli di servizio per le risorse cloud previsti dal NIST (National Institute of Standards and Technology):
- Infrastructure as a Service (IaaS): consiste nel fornire al cliente risorse hardware virtualizzate, come macchine virtuali, storage, reti e altre infrastrutture. Il cliente può installare e gestire i propri sistemi operativi, applicazioni e dati, ma non ha il controllo sulle infrastrutture sottostanti.
- Platform as a Service (PaaS): consiste nel fornire al cliente una piattaforma di sviluppo e distribuzione di applicazioni basata sul cloud. Il cliente può creare e gestire le proprie applicazioni usando i linguaggi, gli strumenti e le librerie forniti dal provider, ma non ha il controllo sulle infrastrutture e i sistemi operativi sottostanti.
- Software as a Service (SaaS): consiste nel fornire al cliente un’applicazione software eseguita sul cloud e accessibile tramite un’interfaccia web o un client leggero. Il cliente può usare l’applicazione per le proprie esigenze, ma non ha il controllo né sulle infrastrutture né sulla piattaforma né sul software sottostanti.
TCO della risorsa cloud
E’ fondamentale capire le differenze delle caratteristiche tecniche di erogazione del servizio insieme a quelle di governo del servizio stesso fornite dall’hyperscaler, per comprendere le implicazioni complessive del servizio.
Ragioniamo in uno sceanrio semplificato di adozione: una sola risorsa cloud e solo due attori. Noi lettori, ci poniamo come utilizzatori del servizio ed abbiamo come unica controparte il fornitore della risorsa cloud, l’hyperscaler.
Propongo l’impiego quattro criteri principali per valutare il modello di servizio da utiizzare per la singola risorsa cloud:
- matrice RACI di responsabilità.
- costo operativo di gestione del ciclo di vita della risorsa cloud
- costo di impiego della risorsa cloud.
- il livello di rischio operativo nell’utilizzo della risorsa
Come per qualsaisi servizio acquistato sarebbe utile conoscere le condizioni di erogazione del servizio e la matrice di responsabilità RACI fornirebbe una buona sintesi, qualora prendesse in considerazione anche la responsabilità sulla sicurezza, sulla protezione dei dati e delle identità digitiali.
Il costo operativo di gestione della risorsa cloud è strettamente legato, come dovrebbe risultare ovvio, alla matrice di responsabilità, che mi dirà in sintesi chi fa e cosa devo fare io per gestire la risorsa cloud da cui dedurre il costo operativo di gestione legato all’impiego del personale addetto (quanto tempo mediamente impiego per configurare, attivare, mantenere, monitorare e gestire il ciclo di vita della risorsa cloud).
Il costo di consumo della risorsa cloud è legato a vari fattori determinati dalla configurazione di impiego della risorsa che immaginiamo in questo scenario semplificato scalabili solo tramite riconfigurazione, dalle politiche di listino prezzi praticato dall’hyperscaler ed influenzate a loro volta dal cambio euro/dollaro e dalla crisi energetica. Quest’ultimo fattore è attenuato solo in parte da contratti a tariffa fissa su periodo che di solito comunque hanno durata massima compresa tra l’anno ed i tre anni.
Con questi quattro criteri in mente proviamo ad effettuare una prima valutazione dei modelli di servizio.
Sarà effettuata una valutazione di alto livello senza entrare nel merito della singola risorsa cloud e del singolo fornitore primario del cloud.
La matrice RACI fornisce una rappresentazione delle responsabilità e guida una valutazione del TCO di una risorsa cloud.
Il TCO di una risorsa cloud può essere esteso al calcolo di un insieme di risorse cloud, che come vedremo è un elemento centrale del modello di servizio cloud native.
Il TCO di una soluzione Cloud è determinato dalla seguente formula che impiega i tre parametri indicati
TCO-Cloud ≅ ∑r TCOLC(r) + ∑r TCOC(r) + ∑r TCORisk(r)
Dove
- r= risorse cloud
- TCOLC(r) è il costo di gestione del ciclo di vita della risorsa cloud
- TCOC(r) = ∑r TCOconsumption(r) + ∑r TCOlicence(r) cioè la composizione del costo del consumo della risorsa sommato all’eventuale costo di licenza
- TCORisk(r) è la stima del costo legato al rischio di impiego della risorsa cloud.
Nel contesto di questo articolo utilizzeremo una valutazione qualitativa dei vari TCO determinandola dalla matrice RACI elaborata.
Utilizzeremo tra valori qualitativi High, Medium, Low
Esempio di riferimento.
Per fornire un caso di studio che possa coprire i tre modelli di servizio si è individuato la fornitura di un servizio di database (non importa il tipo ) il cui accesso deve essere reso disponibile ad una applicazione terza presente sullo stesso network virtuale.
Per rappresentare il modello di servizio database IaaS si tratterà di una risorsa cloud di tipo macchina virtuale che ospiterà un sistema operativo più una istanza .
Per il modello di servizio database PaaS sarà una istanza di un server database
Per il modello di servizio database SaaS sarà una istanza di un database
Caso database IaaS
Nel caso database IaaS il cliente acquista una macchina virtuale dal portale del fornitore primario individuato. La macchina virtuale è l’equivalente di un server fisico virtualizzato indicando le risorse hardware necessarie. Separatamente il cliente deve acquistare il software e le licenze collegate per il sistema operativo e il software di tipo database server. Infine il cliente dovrà allocare personale con competenza sui SO ed un database administrator per completare il processo di installazione e configurazione del server e del database.
La responsabilità del servizio ricade principalmente sul cliente per le componenti software.
Caso database PaaS
Nel caso database PaaS il cliente configura il tipo e l’istanza del database server fornendo i parametri di limite di esecuzione (numero massimo di CPU, ram, spazio disco, più altre configurazioni di base legate alla alta disponibilità e ridondanza geografica, quella locale è sempre garantita dal fornitore); per questa attività è necessaria una figura con esperienza come DBA. Una volta confermato l’ordine verso il fornitore e nel giro di qualche ora sarà in grado di accedere al server installato. A quel punto con un architetto dati potrà configurare l’istanza del database secondo le specifiche applicative fornite. Non deve acquistare licenze software in quanto sono comprese nel prezzo o in alcuni casi può fornire una licenza pre-acquistata con contratti specifici.
In questo caso la responsabilità del servizio è divisa tra il fornitore ed il cliente
Caso database SaaS
Nel caso del database SaaS il cliente acquista solo l’istanza del database, fornire le configurazioni limitate all’impiego del singolo database ed i parametri di alta disponibilità e ridondanza geografica; per questa attività è richiesta una esperienza di tipo architetto dati.
Una volta confermato ordine di acquisto nel giro di qualche ora sarà reso disponibile il servizio di istanza del database (stiamo parlando di uno scenario altamente semplificato).
La responsabilità del servizio ricade completamente sul fornitore primario della risorsa cloud. Il cliente ha la responsabilità nella modello dati implementato e nella logica applicativa implementata (per esempio struttura base dati, viste, chiavi, indici, procedure ecc.)
Proviamo a riassumere quanto illustrato come esempio tramite tre tabelle RACI
Matrice RACI servizio database IaaS
Per il modello di servizio database IaaS (Infrastructure as a Service), una possibile matrice RACI potrebbe essere la seguente:
| Attività | Fornitore IaaS | Cliente IaaS |
|---|---|---|
| Gestione dell’infrastruttura fisica | A/R | I |
| Gestione della rete virtuale | A/R | C |
| Gestione del sistema operativo | C/A | R |
| Gestione delle applicazioni | I | A/R |
| Monitoraggio e backup | C/A | R |
Dove:
- A = Accountable: la persona che approva il completamento dell’attività
- R = Responsible: la persona che esegue l’attività
- C = Consulted: la persona che fornisce input o consigli sull’attività
- I = Informed: la persona che viene informata sull’andamento o sul risultato dell’attività
Matrice RACI servizio database PaaS
Per il modello di servizio PaaS (Platform as a Service), una possibile matrice RACI potrebbe essere la seguente:
| Attività | Fornitore PaaS | Cliente PaaS |
|---|---|---|
| Gestione dell’infrastruttura fisica | A/R | I |
| Gestione della rete virtuale | A/R | I |
| Gestione del sistema operativo | A/R | I |
| Gestione delle applicazioni | C/A | R |
| Monitoraggio e backup | C/A | R |
La differenza principale tra il modello IaaS e il modello PaaS è che nel secondo il fornitore si occupa anche della gestione del sistema operativo, mentre il cliente si concentra solo sullo sviluppo e sul deployment delle applicazioni. Questo significa che il cliente ha meno controllo e flessibilità sulle risorse, ma anche meno oneri e costi di manutenzione.
Matrice RACI servizio database SaaS
Per il modello di servizio SaaS (Software as a Service), una possibile matrice RACI potrebbe essere la seguente:
| Attività | Fornitore SaaS | Cliente SaaS |
|---|---|---|
| Gestione dell’infrastruttura fisica | A/R | I |
| Gestione della rete virtuale | A/R | I |
| Gestione del sistema operativo | A/R | I |
| Gestione delle applicazioni | A/R | I |
| Monitoraggio e backup | A/R | I |
Il modello SaaS è il più completo tra i modelli di cloud computing, in quanto il fornitore si occupa di fornire e gestire tutto il software e l’hardware necessari per erogare il servizio. Il cliente non ha alcuna responsabilità sulla gestione dell’infrastruttura, della rete, del sistema operativo o delle applicazioni, ma si limita a utilizzare il software tramite un’interfaccia web o un’applicazione.
Applicazione del Metodo per TCO database esempio
| TCO | database IaaS | database PaaS | database SaaS |
|---|---|---|---|
| TCOLC | H | M | L |
| TCOconsumption | L | M | M/H |
| TCOlicence | H | M | L |
| TCORisk | H | M | L |
Partendo da questa semplice matrice si potrebbero sviluppare algoritmi di calcolo della stima di vari ordini di complessità; personalmente sconsiglierei questo percorso.
Credo che l’uso migliore sia quello di utilizzare questa matrice come cartina di tornasole di alto livello dell’impiego delle risorse cloud in uso nell’organizzazione.
Il desiderio di ogni IT manager è quello di avere il processo in controllo questa matrice per quanto possa fornire risultati sgradevoli permette di fare una fotografia vera della situazione in corso e permettere di prendere le opportune contro misure dove sia possibile e praticabile o, come avviene nei casi reali, almeno vivere il momento con maggiore realismo e predisporre piani di miglioramento.
Sovente ho incontrato organizzazioni in cui facilmente si valuta solo uno dei vari punti di costo presentati in questo articolo sotto valutando gli altri per poi trovarsi in situazioni di difficile contenimento dei costi.
Il cloud è una servizio con modello di attribuzione del costo diretto non indiretto ed il modello di servizio aziendale deve essere modificato per tenere in grande considerazione questo elemento.
I tempi di reazione del cloud se sono una ottima opportunità dal punto di vista tecnico richiedono una equivalente velocità decisionale da parte dell’organizzazione che di conseguenza dovrà probabilmente modificare il proprio processo di gestione.
Se ne parla più apertamente nell’articolo Il miglior percorso di adozione del cloud dove si tiene conto del livello di maturità IT per il cloud da parte dell’organizzazione aziendale come uno dei fattori determinanti.
Sperando l’articolo vi possa essere stato di aiuto nell’approccio al cloud.
Arrivederci al prossimo!!
Cordialmente
Mauro