Riesco a capire quando c’è un blackout del cloud pubblico perché il mio smartphone esplode con messaggi di giornalisti che vogliono un mio commento sull’impatto di queste interruzioni sulle aziende, sui modi per evitarle e sulla probabilità che questa diventi una tendenza con cui fare i conti da qui in poi. Ammetto che a volte non so cosa rispondere. Dopotutto ciò che è tecnologico, prima o poi, va incontro a dei problemi o dei fallimenti anche gravi. I cloud pubblici non sono diversi. L’obiettivo con la tecnologia è di portare il numero di guasti e interruzioni il più vicino possibile allo zero.

Ha quindi senso cercare soluzioni per ridurre il rischio di interruzioni che interrompono la nostra attività per un certo periodo di tempo. Ultimamente, ciò significa guardare al multicloud per mitigare simili rischi. Multicloud significa sfruttare due o più fornitori di cloud pubblico, ad esempio AWS e Azure, o Azure e Google, o forse anche tutti e tre. Non mettendo tutte le nostre uova in un unico paniere, riduciamo la probabilità che i nostri sistemi possano essere fuori uso a causa di una singola interruzione del cloud pubblico.

Come funzionerebbe questo approccio nei confronti della continuità aziendale? Per proteggerci dall’impatto di una singola interruzione del cloud pubblico, come molti propongono, dobbiamo adottare un approccio di ripristino attivo/attivo. Ciò significa mantenere la stessa applicazione e i dati connessi su due diverse piattaforme cloud. Quando si verifica un’interruzione, è sufficiente eseguire il failover dell’applicazione basata su cloud dal provider cloud principale a un provider cloud secondario e quindi tornare al provider principale al termine dell’interruzione.

Una soluzione che alcuni suggeriscono è quella di spostare l’applicazione e i dati al momento dell’interruzione in un altro provider cloud. Peccato solo che non possiate spostare la vostra copia di lavoro dei dati e la versione corrente dell’applicazione se sono contenute all’interno di un cloud pubblico inutilizzabile. Quindi, saltiamo questa soluzione.

cloud

Il problema con il mantenimento di due versioni della stessa applicazione e dei dati connessi su due o più piattaforme cloud è che ogni fornitore cloud è diverso a livello di funzioni per archiviazione, database, elaborazione, sicurezza, governance e altro. Se si vogliono utilizzare funzionalità cloud-native su entrambi i cloud, che in genere è preferibile, le differenze diventano ancora più problematiche.

Il risultato di questa opzione multicloud è che pagherete due volte gli stessi costi operativi standard e pagherete anche circa il doppio per personalizzare l’applicazione e i dati per un cloud diverso, soprattutto se considerate la necessità di uno sviluppo speciale, database e capacità di amministrazione per ciascuna delle piattaforme. Tutto ciò rende quasi nullo il valore del passaggio a più piattaforme basate su cloud per scopi di interruzione.

Naturalmente, ci sono anche opzioni open source e capacità di portabilità fornite dai container. Sebbene questi forniscano una migliore portabilità, se prevedete di mantenere container identici su due cloud pubblici diversi, ripensateci. Sono infatti richiesti sviluppo e amministrazione specializzati per ogni set di container su ogni cloud pubblico. E anche in questo caso il ROI va rapidamente a farsi benedire.

Invece di utilizzare due o più fornitori cloud, un approccio attivo/attivo migliore sarebbe quello di sfruttare una singola piattaforma cloud e ospitare la stessa applicazione e gli stessi dati in un’area geografica diversa. La maggior parte delle interruzioni che vediamo sono localizzate in una singola regione, con altre regioni che invece rimangono in gran parte inalterate. Un approccio regionale alla continuità aziendale significa maggiori spese per costruire e operare in due sedi, ma molto meno di quanto costerebbe mantenere versioni diverse delle stesse app e dati in esecuzione su piattaforme cloud diverse.

I provider di cloud pubblico hanno goduto di un notevole track record di uptime negli ultimi 10 anni, ma rimane la tentazione di creare una serie di ridondanze per la paura delle interruzioni, anche se a livello pratico (e con ben poche eccezioni) la ridondanza multicloud rimane eccessivamente costosa.