Il cloud è uno dei paradisi della data platform: prestazioni, scalabilità, potenza computazionale, disponibilità di spazio, ecc. Ma uno dei concetti che molti ignorano è che: non puoi avere tutto questo. Non tutto insieme, almeno. Scopri con me uno dei “lati oscuri” se anche tu stai pensando di migrare la tua data platform in cloud.

Sicuramente il cloud ha cambiato la vita di molte realtà aziendali. La scalabilità intrinseca del modello di cloud-computing infatti permette oggi a molte aziende di gestire le proprie risorse in base ai carichi di lavoro ottimizzando i costi.

Uno degli scenari che spesso incontro è quello legato al mondo data platform. Sempre più spesso infatti le aziende stanno migrando le proprie basi dati in cloud, ed in particolare su modelli DBaaS. 

Invece di effettuare il provisioning di macchine virtuali che devono comunque essere gestite, il modello DBaaS permette di lasciare completamente al provider cloud l’onere di gestire l’infrastruttura anche in termini software (gestione sistema operativo, aggiornamenti, ecc).

Tutto questo però porta alla luce delle sfide che spesso in ambienti on-premise sono molto ridotte se non quasi inesistenti.

Parlando di data platform e cloud, una di queste sfide ha a che fare con la latenza di rete.

Oggi molti scenari prevedono delle repliche distribuite a livello globale di un database. Sia per ragioni di sicurezza (nel caso di indisponibilità di un nodo) che di performance (sarai d’accordo con me che se mi trovo in Italia, sarà più facile accedere ai dati se questi sono pubblicati in un datacenter tedesco, piuttosto che statunitense). 

Ed inoltre tali database sono frequentemente soggetti a pesanti carichi di lettura e scrittura. Possono essere stream di dati provenienti da sensori e sistemi IoT, o le transazioni di una grossa catena di supermercati presente in più paesi, o altro ancora.

Spesso la scelta ricade sull’utilizzo di sistemi pensati dal principio per operare in scenari cloud, come CosmosDB di Azure o Dynamo DB di AWS che permettono il provisioning di repliche sia in lettura che in scrittura dei dati in più regioni del mondo in modo semplice e performante.

Hashtag #tuttomoltobello. Ma c’è un lato oscuro.

Il lato oscuro del cloud si chiama “replication lag”

Supponi ad esempio di avere 3 repliche del tuo database: Db1, Db2, Db3 (ho tanta fantasia, vero?). Queste repliche sono pubblicate in 3 regioni del mondo molto distanti tra loro ad esempio: USA, Germania, India.

Ora sul Db1 che si trova in America,scrivi un documento relativo ad un ordine. Poco dopo il solito dato lo troverai nella replica in Germania ed in India.

Ma quanto dopo? Dipende dalla latenza. Quindi non è un valore determinabile!

Infatti, supponi di aver fatto un errore ed eliminare il documento appena scritto in America.

Se, prima che la modifica venga replicata negli altri database, un utente eseguirà una query sugli ordini, troverà il documento che avevi cancellato. Questo perchè il sistema non sarà stato ancora allineato. Vedrà quindi dei dati sporchi.

Per cui, anche se l’esempio è davvero banale, capisci che ci troviamo di fronte a delle decisioni da prendere piuttosto importanti: dare priorità alla disponibilità (leggendo quindi anche dati sporchi o inesistenti) oppure alla coerenza dei dati (attendendo che tutti i sistemi siano allineati)?

A cosa dare la priorità?

Queste “regolazioni” del sistema si chiamano “livelli di consistenza”. Più il livello di consistenza sarà impostato verso il livello “strong” e più i dati saranno coerenti ma a discapito delle performance nel caso i nodi non siano ancora stati allineati all’ultima operazione eseguita.

Se invece imposteremo il sistema verso un livello più performante, avremo meno garanzie sulla consistenza dei dati e sull’ordine delle scritture.

Tali regolazioni sono generalmente presenti nei pannelli di controllo dei servizi cloud. Azure e AWS permettono infatti di gestirle facilmente.

Come detto all’inizio, quando si parla di data platform e cloud, non puoi avere tutto! Devi dare delle priorità! Purtroppo non sono i risultati di una mala progettazione da parte dei provider cloud.

Questi sono gli effetti pratici che derivano dal teorema PACELC descritto da Daniel Abadi (dell’Università di Yale) nel 2010. Tale teorema descrive appunto la necessaria esistenza di compromessi tra consistenza e disponibilità dei dati in ambienti distribuiti.

Nell’illustrazione, una piccola rappresentazione del teorema CAP, predecessore del teorema PACELC. Per ricordare che non si possono ottenere disponibilità, consistenza e tolleranza della partizione.

Questo non è che uno dei tanti fattori che giocano un ruolo determinante nella progettazione e gestione della data platform. E’ chiaro quindi che in questi casi è meglio evitare di improvvisare se non vuoi trovarti in strani ed incomprensibili malfunzionamenti!

Vuoi saperne di più?

Nel mio percorso ho raccolto molte informazioni interessanti in merito agli argomenti di cui ti ho parlato in questo articolo. Per questo ho scritto un libro intitolato “Why Your Data Matter”.

Essendo il frutto della mia passione ed esperienza diretta, ho scelto di mettere questo libro gratuitamente a disposizione di tutti gli IT Manager ed i CIO delle aziende che come te vogliono ottenere grandi risultati dalle loro scelte e dal loro lavoro (evitando di trovarsi in situazioni scomode e da risolvere con urgenza).

Ti invito a leggere le prime pagine scaricandole!

Se poi ti piacerà sarò felice di inviartene una copia GRATUITA direttamente nel tuo ufficio.  

Clicca qui per scaricare l’estratto del mio libro (se ti piacerà te lo invierò in formato cartaceo!) ==> il mio libro