Tankeledere
Begynn å forberede deg nå for den neste skyutbruddet

Store skyhendelser som denne uken fra AWS er uunngåelige. Disse fire metodene kan hjelpe ditt firma å gjennomføre.
Med talløse timer med tapt produktivitet, finanssystemer som ble avbrutt for millioner av brukere, og potensielt hundre milliarder dollar tapt, var denne uken skyutbruddet fra AWS en uansett dårlig dag for globale IT-team. Selvfølgelig var det også den verste globale skykatastrofen siden den siste…og til den neste.
Uansett om du er på AWS, GCP, Azure eller en annen plattform, er store utbrudd en del av skydataproduksjonens virkelighet. Hva kan ditt firma da gjøre for å mildne slaget? Under vil jeg tilby fire trinn som ditt team kan ta umiddelbart.
Bring din skeptisisme – og gjør din hjemmelekse.
Ofte vil teamene gå mot katastrofen ved å gå inn i skyarrangementer med antagelsen om at store sky-selskaper er innebygd pålitelige. For å være sikker, har de mest pålitelige selskapene tjent sin rykte for en grunn. Samtidig tilbyr hver sky og hyperskalerer et stort utvalg av infrastrukturvalg – AWS Nord-Amerika alene har 31 tilgjengelighetsområder og 31 kantnøkkelområder – og noen valg er mye mer pålitelige enn andre.
I virkeligheten var AWS sin US-EAST-1-region, årsaken til denne uken utbrudd, bak store forstyrrelser i 2020, 2021 og 2023, og det var lenge kjent i visse IT-kretser som den minst pålitelige regionen. Mange selskaper forstod sannsynligvis situasjonen, men tok en kalkulert risiko på grunn av regionens lave kostnad og rike tilbud. Men gitt omfanget av utbruddet, er det umulig å ikke overveie hvor mange selskaper ble tatt fullstendig overrasket – og ville sikkert valgt de mer pålitelige regionene hvis de hadde vært klar over kompromissene. Jeg har personlig møtt IT-ledere som valgte å flytte til andre AWS-regioner bare etter dårlige erfaringer med US-EAST-1 i fortiden.
Lektionen her er å gjøre din hjemmelekse når det gjelder sky-infrastrukturvalg, uansett hvilken sky du arbeider med. Steder å starte inkluderer gratis verktøy som cloudprice, Cloudping, og de historiske hendelsesvisningene fra hyperskaler-providerte Cloud Service Health-verktøy.
Velg bærbart over sky-nativt.
Når du designer skykonfigurasjoner, er den enkleste veien å gå sky-nativt. Men mens det er praktisk å velge applikasjoner som er ferdigbygget av og for din sky-tilbyder, etterlater disse sky-native valgene deg mer utsatt hvis din sky går ned.
For å unngå den ekstra lag av sky-avhengighet, velg uavhengige og/eller åpne kildeprodukter hvor mulig. Noen eksempler på erstatninger inkluderer de nedenfor:
|
Kategori |
Nativt tilbudseksempel |
Åpne kildealternativer inkluderer… |
|
Autentisering og identitet |
AWS Cognito |
Keycloak |
|
Søk |
Azure Monitor |
Elasticsearch |
|
Relasjonelle databaser |
Google Cloud SQL |
PostgreSQL |
|
NoSQL-databaser |
AWS DynamoDB |
MongoDB |
|
Container-orkestrasjon |
Azure Kubernetes Service (AKS) |
Kubernetes |
|
Overvåking og observasjon |
Google Cloud Monitoring |
Prometheus + Grafana |
|
Meldingskøer |
AWS SQS/SNS |
Apache Kafka |
|
Objektlagring |
Azure Blob Storage |
MinIO |
|
API-gateway |
Google Cloud API Gateway |
Kong |
For å være sikker, å bygge mer av din sky-stakk fra bunnen av betyr mer arbeid for ditt team. Likevel, i min erfaring, en gang du har infrastrukturen opp og kjører, er det lite eller ingen forskjell på å legge til arbeidsbyrde til en etablert hjemmebygd infrastruktur eller å operere på en sky-nativ en. Og fordelen i form av motstandskraft – ikke til å nevne redusert sky-låsning – gjør uavhengige valg svært verdifulle.
Konstruer for feil.
Gitt at skyfeil vil skje, må du sørge for å designe dine produkter med skyfeil i mente. Et eksempel å se på er Datadog: i en hendelse i 2023, mistet selskapet plutselig tilgang til over halvparten av sine Kubernetes-noder i produksjon og fullstendig omkonstruerte sin katastrofe-tilnærming som respons. Endringer inkluderte å fjerne arkitektoniske flaskenakker og å håndtere teknisk gjeld så at delvise feil ikke ville skje gjennom systemet, å forbedre datainntak og lagring for større data-tilgjengelighet under utbrudd, og å bygge systemer som automatisk gjenoppretter i skala. En god plass å starte på din reise er å følge Datadogs anbefaling om å “starte med hva som er viktig for sluttbrukeren” og bygge sikkerhetskopier for å beskytte hva som betyr mest.
Kjør på minst to skyer.
Selvfølgelig er den beste måten å ikke være avhengig av skyfeil å ha multicloud-redundans. Å oppnå sann multicloud-flytighet er en stor oppgave for mange selskaper, siden det er ekstremt vanskelig å oversette infrastruktur fra en sky til en annen. Men å bygge ut infrastruktur på bare to skyer er en sterk – og ofte gjennomførbare – plass å starte. Kritisk for å gjøre dette til å fungere er å ha et team på plass med en ekspert i hver av skyene du kjører på.
For å være sikker, kan ingenting skjerme selskaper fullstendig fra effekten av et massivt utbrudd som det vi så denne uken. Men med riktig due diligence, en sky-portabel tilnærming, konstruksjon for feil og bruk av “dual-cloud” som en stegstein til sann multicloud, kan selskaper være mye mer smidige når den neste (og dessverre uunngåelige) store sky-hendelsen inntreffer.












