Leader di pensiero

Inizia a prepararti ora per il prossimo guasto cloud

mm
Aggiungi Unite.AI alle tue fonti preferite su Google

Gli incidenti cloud importanti come quello di questa settimana da AWS sono inevitabili. Questi quattro metodi possono aiutare la tua azienda a superare la situazione.

Con innumerevoli ore di produttività persa, sistemi finanziari interrotti per milioni di utenti, e potenzialmente centinaia di miliardi di dollari persi, il guasto di AWS di questa settimana è stato senza dubbio un giorno terribile per i team IT globali. Naturalmente, è stato anche il peggior disastro cloud globale dal ultimo… e fino al prossimo.

Indipendentemente dal fatto che tu utilizzi AWS, GCP, Azure o qualsiasi altra piattaforma, i guasti importanti sono una realtà del cloud computing. Quindi, cosa può fare la tua azienda per mitigare l’impatto? Di seguito, offrirò quattro passaggi che il tuo team può intraprendere immediatamente.

Porta con te il tuo scetticismo – e fai i tuoi compiti.

Spesso, i team si precipitano nel disastro pensando che le grandi aziende cloud siano intrinsecamente affidabili. Certo, le aziende più affidabili hanno guadagnato la loro reputazione per una ragione. Tuttavia, ogni cloud e hyperscaler offre una vasta gamma di opzioni di infrastruttura – AWS Nord America da solo ha 31 Zone di disponibilità e 31 Posizioni di rete Edge – e alcune opzioni sono molto più affidabili di altre.

In effetti, la regione US-EAST-1 di AWS, la causa del guasto di questa settimana, era stata dietro a importanti interruzioni nel 2020, 2021 e 2023, e era nota in certi ambienti IT come la regione meno affidabile. Molte aziende hanno probabilmente capito la situazione, ma hanno preso un rischio calcolato dato il basso costo e le numerose offerte della regione. Tuttavia, data la portata del guasto, è impossibile non considerare quanti team siano stati colti completamente di sorpresa – e avrebbero sicuramente optato per regioni più affidabili se fossero stati a conoscenza dei compromessi. Ho personalmente incontrato leader IT che hanno scelto di spostarsi in altre regioni AWS solo dopo esperienze negative con US-EAST-1 in passato.

La lezione qui è di fare i propri compiti quando si tratta di opzioni di infrastruttura cloud, indipendentemente dal cloud che si sta utilizzando. I punti di partenza includono strumenti gratuiti come cloudprice, Cloudping, e le visualizzazioni storiche degli incidenti da strumenti di salute dei servizi cloud forniti dagli hyperscaler.

Scegli portabile anziché cloud-native.

Quando si progettano configurazioni cloud, la strada più semplice è quella di utilizzare il cloud-native. Tuttavia, sebbene sia conveniente selezionare applicazioni pronte all’uso create dal e per il proprio fornitore cloud, queste opzioni cloud-native lasciano l’azienda più esposta se il cloud va giù.

Per evitare quel livello aggiuntivo di dipendenza dal cloud, opta per prodotti indipendenti e/o open-source quando possibile. Alcuni esempi di sostituzioni includono quelli elencati di seguito:

Categoria

Esempio di offerta nativa

Alternative open-source includono…

Autenticazione e identità

AWS Cognito

Keycloak

Ricerca

Azure Monitor

Elasticsearch

Database relazionali

Google Cloud SQL

PostgreSQL

Database NoSQL

AWS DynamoDB

MongoDB

Orchestrazione dei container

Azure Kubernetes Service (AKS)

Kubernetes

Monitoraggio e osservabilità

Google Cloud Monitoring

Prometheus + Grafana

Code messaggi

AWS SQS/SNS

Apache Kafka

Archiviazione oggetti

Azure Blob Storage

MinIO

Gateway API

Google Cloud API Gateway

Kong

Certo, costruire più della propria pila cloud da zero significa più lavoro per i team. Tuttavia, nella mia esperienza, una volta che si ha l’infrastruttura in funzione, non c’è quasi nessuna differenza tra l’aggiungere carichi di lavoro a un’infrastruttura domestica stabilita o a un’infrastruttura cloud-native. E i benefici in termini di resilienza – per non parlare della riduzione della dipendenza dal cloud – rendono le opzioni indipendenti estremamente valide.

Progetta per il fallimento.

Dato che i fallimenti cloud si verificheranno, assicurati di progettare i tuoi prodotti tenendo presente il fallimento cloud. Un esempio da esaminare è Datadog: in un incidente del 2023, l’azienda ha improvvisamente perso l’accesso a oltre la metà dei suoi nodi Kubernetes in produzione e ha completamente riprogettato il suo approccio ai disastri in risposta. I cambiamenti hanno incluso la rimozione di collo di bottiglia architettonici e l’addressing del debito tecnico in modo che i fallimenti parziali non si propagassero attraverso il sistema, il miglioramento dell’ingestione e dell’archiviazione dei dati per una maggiore disponibilità dei dati durante gli outage, e la costruzione di sistemi per recuperare automaticamente a livello di scala. Un ottimo punto di partenza nel tuo percorso è seguire la raccomandazione di Datadog di “iniziare con ciò che è importante per l’utente finale” e costruire salvaguardie per proteggere ciò che più conta.

Esegui su almeno due cloud.

Naturalmente, il modo migliore per non essere vincolati dai fallimenti cloud è la ridondanza multicloud. Raggiungere una vera fluidità multicloud è un’impresa enorme per molte aziende, poiché è estremamente difficile tradurre l’infrastruttura da un cloud all’altro. Tuttavia, costruire l’infrastruttura su solo due cloud è un punto di partenza forte – e spesso fattibile. Fondamentale per far funzionare questo approccio è avere un team con un esperto in ciascuno dei cloud su cui si sta eseguendo.

Certo, nulla può proteggere completamente le aziende dall’impatto di un guasto massive come quello che abbiamo visto questa settimana. Tuttavia, con la giusta diligenza, un approccio portatile cloud, la progettazione per il fallimento e l’utilizzo del “dual-cloud” come trampolino di lancio per il vero multicloud, le aziende possono essere molto più agili quando si verifica il prossimo (e purtroppo inevitabile) grande incidente cloud.

Harshit Omar è il Co-Fondatore e CTO di FluidCloud, dove sta costruendo il futuro dell'infrastruttura cloud - abilitando le aziende a migrare, replicare e ottimizzare i carichi di lavoro in ambienti cloud multipli. In precedenza, è stato il primo ingegnere di Accurics, dove ha guidato gli sforzi di sviluppo core per il suo motore di policy e la piattaforma di sicurezza cloud.

Con una profonda esperienza in Go, Kubernetes, Terraform e conformità cloud, Harshit ha trascorso oltre un decennio progettando sistemi resilienti su AWS, Azure e GCP.

La sua missione ora è quella di eliminare il lock-in cloud e rendere l'infrastruttura così portatile e resiliente come il codice.