Una nuvola a bilancio

Suggerimenti per generare risparmi grazie all’utilizzo di sistemi cloud

Italia Nuvola

di Daniele Pizzolli, Matteo Vabanesi e Fabrizio De Rosa, Team Cloud Italia del Dipartimento per la trasformazione digitale

C’è una regola non scritta tra gli amministratori di sistema on premise: se tutto funziona, non cambiare configurazione. Una consuetudine che non sempre risulta però ottimale quando si passa al cloud, soprattutto quando si parla di bilanci e di contabilità. Grazie al cloud, infatti, le amministrazioni possono generare considerevoli risparmi e migliorare la gestione complessiva dei servizi. Ma come fare? Quali sono le voci di costo sulle quali agire?

Il primo passo è sicuramente quello di monitorare in maniera costante la spesa cloud, un aspetto fondamentale (come sappiamo) per favorire un’efficace allocazione di risorse. Purtroppo, però, tracciare i consumi senza entrare nel merito del contenimento dei costi non è sufficiente, anche alla luce di possibili disallineamenti fra le previsioni di spesa e l’effettivo fabbisogno di risorse collegato a una migrazione in cloud di dati e sistemi informativi. Vediamo alcuni esempi.

Perché i costi sembrano aumentare dopo una migrazione in cloud

Delineare con precisione una matrice dei costi è un’operazione molto complessa, dato che ogni singolo ente può essere considerato come un caso particolare, sia per composizione del conto economico sia per offerta di servizi e forniture. È il motivo per cui, nella stima dei costi, le amministrazioni possono incorrere nel rischio di errori di valutazione, imprecisioni in buona parte riassumibili nelle seguenti tipologie, elencate non in ordine di importanza:

Come rendere effettivo il risparmio grazie al cloud

Anzitutto è necessario sottolineare che in caso di errato censimento dei servizi da migrare in cloud non è possibile attuare alcuna strategia di mitigazione. La buona notizia, però, è che in tutti gli altri casi si possono mettere in campo soluzioni ad hoc per rendere effettivi i risparmi.

Lavorare con il cloud, infatti, rende subito evidenti i costi sottesi alle scelte.

Per esempio, lo storage si paga a consumo e quindi i log vecchi, i risultati delle build oppure i file temporanei, che in un’infrastruttura locale potevano essere dimenticati su dischi comprati e ammortizzati, devono invece essere ruotati, processati, eventualmente compressi ed archiviati in storage a basso costo, oppure eliminati.

Utilizzare una classificazione per tag (o label, per parole chiave) dei servizi attivati in cloud permette di capire dove vengono spese le risorse, e iniziare a dimensionare al meglio le forniture.

Così se l’amministrazione dispone di tre siti web, per semplicità ognuno associato ai servizi di front-end, back-end e storage, con opportune etichette è possibile raggruppare i costi per singolo sito o per servizio, e individuare eventuali correttivi dove le spese sono meno ottimizzate.

Un altro esempio può riguardare l’esistenza di processi duplicati o ridondanti, oppure semplicemente inefficienti. Il caso classico è quello dei cloud provider che si fanno pagare i dati in uscita. Se l’utilizzo di servizi basati su sincronizzazione dati non generava costi all’interno di un’infrastruttura locale, con la migrazione in cloud le spese sostenute per gli stessi servizi sono destinate ad aumentare in maniera significativa. Anche in questo caso, però, la soluzione è semplice: basta modificare il processo di sincronizzazione, passando, ad esempio, da una copia intera a una copia differenziale, per ridurre di conseguenza le spese.

Dove iniziare a mappare gli sprechi

Non occorre essere FinOps (la figura professionale che si occupa del monitoraggio continuo dei sistemi cloud) per iniziare a mappare gli sprechi, anche se, come ovvio, avvalersi di personale specializzato è sicuramente un punto di forza. Questo perché, come abbiamo visto, il primo problema da affrontare è di natura culturale: se tutto funziona, allora non toccare niente. Che significa nessuna riconfigurazione dei servizi cloud. Anche perché, se qualcosa andasse storto, tutti sarebbero pronti a lamentarsi. Quindi per quale motivo prendersi dei rischi?

Eppure è proprio dietro le quinte, mentre tutto “funziona” alla perfezione o quasi, che è possibile attuare delle strategie di risparmio.

Ad alto livello, una razionalizzazione delle modalità di gestione del ciclo di vita del software, mediante metodologie e strumenti condivisi e uniformi, dovrebbe aiutare a consolidare l’esperienza degli operatori, come gli amministratori di rete e di sistema oppure i DevOps.

Ad esempio, se i servizi sono distribuiti su macchine virtuali (virtual machines), magari con diversi software di gestione (hypervisor) e sistemi di orchestrazione di container (cluster kubernetes), sarà necessario avere un esperto in ogni dominio; mentre riuscire a convogliare tutto su un cluster kubernetes, o comunque verso un’architettura nativa cloud, significa sfruttare al meglio le conoscenze del gruppo di lavoro.

Certo, qui entra fortemente in gioco la dimensione della squadra che si occupa della gestione ordinaria, le cosiddette operations: gruppi di lavoro dalle dimensioni ridotte dovranno necessariamente concentrare gli sforzi, mentre avere un team dedicato permette di esplorare soluzioni a più ampio respiro, che consentono anche elevati risparmi. In ogni caso, c’è comunque da sottolineare un aspetto: più le componenti del software utilizzato per gestire servizi cloud appartengono a una soluzione proprietaria, e quindi “chiusa”, più sarà difficile ottimizzare i costi di gestione per un team interno.

Molto spesso, infatti, i fornitori di software (vendor) raccomandano determinate specifiche di macchine virtuali che potrebbero risultare sovradimensionate. Se con le soluzioni on premise questo comportava, per l’ente, l’acquisto una tantum di un server più potente, con il paradigma cloud ciò significa invece sostenere ogni mese dei costi per risorse inutilizzate, come ad esempio CPU e licenze (che di solito sono legate al numero di CPU).

Ottimizzare un’applicazione per il cloud consente di generare risparmi considerevoli, a fronte di un investimento iniziale comunque rilevante.

Ogni applicazione fa storia a sé, ma in generale la migrazione verso un’architettura a microservizi renderà evidenti i servizi più avidi di risorse, indicando la strada per ulteriori semplificazioni. Ad esempio, l’auto-scaling, ovvero l’aumento di risorse per una data applicazione in seguito all’aumento di richieste (immaginiamo un picco di collegamenti al lancio di una nuova iniziativa o all’avvicinarsi della scadenza) gestito in maniera automatica e dinamica dal sistema, è un modo per bilanciare le prestazioni con le spese.

In generale, il consuntivo dei costi nel cloud dovrebbe essere mantenuto al di sotto del 10% di scostamento da quanto preventivato. Ma come trovare il giusto bilanciamento tra costi e servizi cloud offerti dai provider?

Una soluzione potrebbe essere quella di testare diverse taglie di macchine virtuali, oppure il dimensionamento dei cluster a disposizione. Questo naturalmente presuppone che ci siano dei test automatizzati e dei report di prestazioni che guidino nell’ottimizzazione. Se questi non sono presenti, andare per tentativi potrebbe risultare lungo e poco fruttuoso.

Nuovole Bilancie

Come bilanciare il risparmio con le esigenze di sistema

Se si vuole ottenere un risparmio, o per lo meno contenere le spese, migrare dati e servizi in cloud non dovrebbe limitarsi a un semplice lift and shift.

Ogni servizio andrebbe analizzato per essere adattato alla flessibilità del cloud.

Ad esempio, le elaborazioni periodiche, fatte dietro le quinte, come la generazione di avvisi a una certa scadenza, di solito non necessitano di prestazioni garantite e sono un ottimo esempio di lavoro che può essere delegato a istanze non garantite, che non devono soddisfare requisiti stringenti in termini di performance.

Un’altra situazione ricorrente riguarda gli ambienti di test pre-produzione e il buon funzionamento dei sistemi di backup. In questi casi, infatti, non è necessario avere a disposizione delle macchine virtuali garantite, perché le prestazioni non sono importanti e i dati possono essere creati e distrutti all’occorrenza. Se un test dovesse fallire a causa delle performance non elevate del sistema, sarebbe comunque semplice accorgersene e rilanciare la sessione di test. L’attesa di un nuovo ciclo verrà comunque bilanciata dal risparmio generato.

Un’altra possibilità per generare risparmi è quella di effettuare una ricognizione sulle scontistiche del cloud provider, che spesso offrono pacchetti con varie scadenze e dimensioni. Si possono trovare sconti importanti, se vengono sottoscritti impegni per determinati livelli di consumo annuali oppure, come spesso avviene, per i successivi tre anni; così come è possibile generare risparmi se si scelgono prestazioni limitate, con addirittura lo spegnimento senza preavviso di alcune macchine in caso di scarso utilizzo — macchine che in realtà il cloud provider assegnerà in tempo reale ad altri destinatari.

Ogni cloud provider prevede un set di servizi più o meno compatibili con quelli offerti dalle altre aziende concorrenti. Maggiore è l’acquisto (e l’utilizzo) di servizi diffusi, più sarà facile migrare da un cloud provider all’altro per ottimizzare i costi, specialmente — lo ribadiamo — se questi sono basati su standard aperti o software libero.

Purtroppo, infatti, sono noti alcuni casi in cui fornitori di software, una volta acquisita la proprietà di una tecnologia molto diffusa presso i cloud provider, hanno incrementato considerevolmente il costo delle licenze d’uso, con inevitabili ripercussioni sui costi delle aziende che offrono servizi cloud e sui loro clienti. In una situazione simile è chiaro che minimizzare il lock-in, magari con una strategia multi-cloud, permette alle amministrazioni di rispondere con la massima flessibilità agli aumenti di spesa, spostando parte delle infrastrutture cloud su altri sistemi più economici, nel minor tempo possibile.

Memento: come evitare casi limite

È interessante notare che una gestione poco oculata dei sistemi cloud può portare anche a dei casi limite, nei quali le amministrazioni si trovano a dover sostenere delle spese per errori di configurazione altrui. Alcuni costi sono infatti calcolati per numero di accessi a una determinata risorsa, ad esempio il numero di volte che un file viene scaricato dall’ object storage — una sorta di archivio virtuale di documenti digitali. Semplificando, è così sufficiente che per sbaglio — o per dolo — venga configurato un software in maniera errata perché uno stesso file venga scaricato milioni di volte, facendo così esplodere i costi di gestione cloud.

Si tratta, purtroppo, di un abuso che si è realmente verificato (per fortuna poi risolto senza conseguenze, salvo le notevoli perdite di tempo). In generale, però, risulta evidente come l’assenza di un monitoraggio costante dei servizi, oltre alla mancata limitazione degli accessi che ci vengono addebitati, può tradursi in spiacevoli sorprese.

Un’analisi puntuale delle soglie di traffico, insieme a un’attenta osservazione periodica del funzionamento dei sistemi, permette così di rivalutare i costi, come sottolineato anche nella sezione dedicata del Manuale di abilitazione al cloud messo a disposizione dal Dipartimento per la trasformazione digitale.

La normalità del cloud, infatti, è il continuo cambiamento, e senza questa consapevolezza è difficile fare passi avanti, anche nel contenimento delle spese.

Le immagini presenti in questo articolo sono state sviluppate con il supporto dell’Intelligenza Artificiale con l’obiettivo di rappresentare visivamente i temi trattati.

Questo blog è redatto da Developers Italia