Tankeledare

Börja förbereda dig nu för nästa molnavbrott

mm
Lägg till Unite.AI bland dina föredragna källor på Google

Stora molnincidenter som den vi såg denna vecka är oundvikliga. Dessa fyra metoder kan hjälpa ditt företag att hantera situationen.

Med otaliga timmar av förlorad produktivitet, finansiella system som störts för miljontals användare, och potentiellt hundratals miljarder dollar förlorade, var denna veckas AWS-avbrott en obehaglig dag för globala IT-team. Det var förstås också den värsta globala molnkatastrofen sedan den senaste… och till den nästa.

Oavsett om du använder AWS, GCP, Azure eller någon annan plattform, är stora avbrott en del av molnverkligheten. Vad kan ditt företag göra för att mildra effekterna? Nedan kommer jag att ge fyra steg som ditt team kan vidta omedelbart.

Var skeptisk – och gör din läxa.

Ofta går team mot katastrof genom att gå in i molnavtal med antagandet att stora molnföretag är inhämtat pålitliga. Det är sant att de mest pålitliga företagen har förtjänat sin rykte av en anledning. Samtidigt erbjuder varje moln och hyperscaler ett brett utbud av infrastrukturalternativ – AWS Nordamerika har 31 tillgänglighetszoner och 31 Edge-nätverksplatser – och vissa alternativ är betydligt mer tillförlitliga än andra.

Faktum är att AWS: s US-EAST-1-region, som orsakade denna veckas avbrott, hade varit bakom stora störningar 2020, 2021 och 2023, och det var länge känt i vissa IT-kretsar som den minst tillförlitliga regionen. Många företag förstod förmodligen situationen men tog en kalkylerad risk med tanke på regionens låga kostnad och rikliga utbud. Men med tanke på avbrottets omfattning är det omöjligt att inte fundera på hur många företag som togs helt på sängen – och skulle ha valt de mer tillförlitliga regionerna om de hade varit medvetna om kompromissen. Jag har personligen träffat IT-chefer som valde att flytta till andra AWS-regioner efter dåliga upplevelser med US-EAST-1 i det förflutna.

Lektionen här är att göra din läxa när det gäller molninfrastrukturalternativ, oavsett vilket moln du arbetar med. Platser att börja på inkluderar gratisverktyg som cloudprice, Cloudping, och de historiska incidentvyerna från hyperscaler-tillhandahållna Cloud Service Health-verktyg.

Välj portabelt över molntillverkat.

När du konstruerar molnkonfigurationer är den enklare vägen att gå molntillverkat. Men medan det är bekvämt att välja applikationer som är färdigbyggda av och för din molntjänst, lämnar dessa molntillverkade alternativ dig mer utsatt om ditt moln går ner.

För att undvika den extra lagern av molnberoende, välj oberoende och/eller öppen källkodsprodukter där det är möjligt. Några exempel på ersättningar inkluderar de nedan:

Kategori

Inbyggt erbjudandeexempel

Öppen källkodsalternativ inkluderar…

Autentisering och identitet

AWS Cognito

Keycloak

Sökning

Azure Monitor

Elasticsearch

Relationella databaser

Google Cloud SQL

PostgreSQL

NoSQL-databaser

AWS DynamoDB

MongoDB

Containerorkestrering

Azure Kubernetes Service (AKS)

Kubernetes

Övervakning och observerbarhet

Google Cloud Monitoring

Prometheus + Grafana

Meddelandeköer

AWS SQS/SNS

Apache Kafka

Objektlagring

Azure Blob Storage

MinIO

API-gateway

Google Cloud API Gateway

Kong

Det är sant att bygga mer av din molnstapel från grunden innebär mer arbete för dina team. Men i min erfarenhet, när du har infrastrukturen uppe och körs, finns det lite eller ingen skillnad mellan att lägga till arbetsbelastning till en etablerad hemmagjord infrastruktur eller att köra på en molntillverkad. Och fördelarna i form av motståndskraft – för att inte tala om minskat molnbundet – gör oberoende alternativ mycket värdefulla.

Konstruera för fel.

Med tanke på att molnfel kommer att ske, se till att konstruera dina produkter med molnfel i åtanke. Ett exempel att titta på är Datadog: i en incident 2023 förlorade företaget plötsligt åtkomst till över hälften av sina Kubernetes-noder i produktion och omkonstruerade helt sin katastrofmetod som svar. Förändringar inkluderade att ta bort arkitektoniska flaskhalsar och hantera teknisk skuld så att partiella fel inte skulle skapa en kedjereaktion genom systemet, förbättra datainmatning och lagring för ökad datatillgänglighet under avbrott, och bygga system för att automatiskt återhämta sig i stor skala. En bra plats att börja på är att följa Datadogs rekommendation att “börja med vad som är viktigt för slutanvändaren” och bygga säkerhetsåtgärder för att skydda det som är viktigast.

Kör på minst två moln.

Det bästa sättet att inte vara beroende av molnfel är molnredundans. Att uppnå sann molnfluiditet är en enorm uppgift för många företag, eftersom det är extremt svårt att översätta infrastruktur från ett moln till ett annat. Men att bygga ut infrastruktur på bara två moln är en stark – och ofta genomförbar – plats att börja på. Kritiskt för att göra detta är att ha ett team på plats med en expert inom varje moln som du kör på.

Det är sant att ingenting kan skydda företag helt från effekterna av ett massivt avbrott som det vi såg denna vecka. Men med rätt due diligence, en molnportabel approach, konstruktion för fel och användning av “dual-cloud” som en trappsteg till sann moln, kan företag vara betydligt mer smidiga när nästa stora molnincident slår till.

Harshit Omar är medgrundare och CTO för FluidCloud, där han bygger framtiden för molninfrastruktur - möjliggör för företag att sömlöst migrera, replikera och optimera arbetsbelastningar i multi-molnmiljöer. Han var tidigare den första ingenjören på Accurics, där han ledde kärnutvecklingsinsatserna på dess policy-motor och molnsäkerhetsplattform.

Med djup expertis inom Go, Kubernetes, Terraform och molnsäkerhet har Harshit tillbringat över ett decennium med att designa robusta system över AWS, Azure och GCP. Hans uppdrag nu är att eliminera moln-låsning och göra infrastruktur lika portabel och robust som kod.