Leader di pensiero
Inizia a prepararti ora per il prossimo guasto cloud

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.












