Perché avere una strategia multi-cloud?

In Cerved ci siamo dotati di una strategia multi-cloud. Il caso che descriveremo di seguito non ha la pretesa di raccontarne tutte le opportunità, bensì descrive un’esperienza pratica maturata e non necessariamente replicabile in tutti i contesti.

Nell’immagine qui sotto l’attuale configurazione cloud di Cerved.

Anzitutto una premessa. Per sfruttare al meglio un’architettura multi-cloud occorrono:

– un account operativo su due diversi Cloud Service Provider (CSP)

– una componente di networking cross cloud.

Innanzitutto, abbiamo bisogno di dati e misurazioni.

Ecco alcune metriche sulle quali ci siamo basati per valutare lo spostamento da un Cloud Solution Provider a un altro.

I Public Cloud sono tutti diversi tra loro. Si può scegliere tra feature più utili e servizi migliori; ad esempio, sulle macchine virtuali, alcuni Cloud Service Provider (CSP) ci obbligano a scegliere fra combinazioni fisse di CPU e RAM, altri invece danno piena libertà di customizzazione.

Lo stesso servizio può avere costi significativamente diversi pur mantenendo identico il livello di prestazioni. I piani di sconti ed incentivi sono diversi tra loro ed averne più di uno consente di scegliere il più adatto.

Non dipendere da un solo CSP produce migliori condizioni contrattuali per effetto della concorrenza e aumenta la resilienza in caso di problemi. Inoltre, utilizzando metodologia IaC (Infrustructure as Code) con strumenti terzi come Terraform, è possibile migrare con relativa semplicità da un CSP all’altro senza dover ricostruire l’intera infrastruttura “manualmente”.

A parità di servizi e costi (ad esempio Virtual Machine e storage) le performance non sono sempre uguali e poter scegliere dove far funzionare un workload è una grande opportunità. La qualità delle prestazioni offerte ovvero la velocità di elaborazione di uno stesso workload o la possibilità nello stesso tempo di elaborarne di più complessi. Valori come RPO (Recovery Point Objective) ed RTO (Recovery Time Objective) sono parametri utili capire i livelli di servizio erogabili soprattutto su prodotti.

Il lato oscuro di ogni cloud è la latenza, ovvero il tempo impiegato dalle richieste del nostro cliente per ricevere una risposta dall’applicazione. Per alcune applicazioni è importante utilizzare un CSP con region contigue a quelle dei clienti. È quindi opportuno valutare una distribuzione omogenea dei propri datacenter in modo da presidiare le aree geografiche dei clienti, riducendo così la latenza.

Innanzitutto, per scegliere abbiamo bisogno di dati e quindi misurazioni. Le metriche sulle quali ci siamo basati per valutare lo spostamento da un CSP all’altro sono:

– Consumi, ovvero la misurazione a livello di billing di eventuali differenze di costi da un CSP all’altro, a parità di servizio/componente, chiaramente la differenza dev’essere rilevante per giustificare i costi ed i rischi di una migrazione;

– Tempi di elaborazione, la qualità delle prestazioni offerte ovvero la velocità di processamento di uno stesso workload o la possibilità nello stesso tempo di elaborarne di più complessi, sono elementi facilmente misurabili e da tenere in grande considerazione come criterio di scelta.

– Features, le caratteristiche fornite come ad esempio un servizio particolare di storage con elevate prestazioni di Input/Output sono un altro utile elemento di misurazione “su strada” come vedremo a breve.

– Resilienza, valori come RPO (Recovery Point Objective) ed RTO (Recovery Time Objective) vanno misurati per capire quali sono i livelli di servizio erogabili soprattutto su prodotti mission critical.

Per Cerved, applicando le metriche appena descritte ad alcune componenti, si è giunti a una short list di possibili migrazioni e quindi a valutare un’eventuale migrazione ad un CSP più performante.

Analizzando i dati prodotti dalle metriche si è giunti a migrare un mongodb replica set di grosse dimensioni (420TB compressi), sulla base di queste evidenze:

– Vantaggi Economici significativi, ad esempio un risparmio sui costi maggiore o uguale al 20%.

– Autoconsistenza, ovvero il componente doveva essere collegato al minor numero di altri componenti (applicazioni, servizi, database ecc.) in modo da contenere i rischi ed i tempi di migrazione.

– Effort di migrazione, la durata ed il costo della migrazione devono essere contenuti per evitare di bruciare i vantaggi economici della stessa migrazione, durante la migrazione è quasi sempre necessario lasciare in esercizio il componente su entrambi i CSP in parallelo raddoppiando i costi e l’impegno amministrativo per tale periodo.

– Compatibilità, è importante scegliere il componente che può continuare ad usare gli stessi elementi (ad es.: versione di sistema operativo, tipologia di CPU ecc..) in uguale versione sul nuovo CSP in modo da non doversi sobbarcare anche di altre migrazioni tecnologiche in caso di differenza.

A distanza di qualche mese da questa operazione è possibile fare un primo bilancio di questa esperienza Cerved.

Primo: il risultato immediato è stato un miglioramento delle prestazioni. I nostri test hanno dimostrato che in assenza di cache, ovvero per query non presenti in memoria, i tempi di risposta sono dimezzati.

Secondo: in termini economici è prevista una riduzione dei costi del 20% per questo anno e del 30% per il prossimo.

I riscontri sono quindi del tutto positivi, ma potrebbero non essere adatti in tutti i contesti.

Vuoi saperne di più? Leggi il nostro precedente articolo sul Cloud Cerved