Start forberedelsen nu til det næste cloud-afbrud

Store cloud-ulykker som denne uges fra AWS er uundgåelige. Disse fire metoder kan hjælpe din virksomhed med at komme igennem.

Med utallige timer med tabt produktivitet, finansielle systemer forstyrret for millioner af brugere, og potentielt hundreder af milliarder dollars tabt, gjorde denne uges AWS-afbrud til en ubestridt dårlig dag for globale IT-hold. Selvfølgelig var det også den værste globale cloud-katastrofe siden den sidste… og indtil den næste.

Uanset om du er på AWS, GCP, Azure eller en anden platform, er store afbrud en given del af cloud computing-reality. Så hvad kan din virksomhed gøre for at mindske slaget? Herunder vil jeg give fire trin, som dit hold kan tage med det samme.

Bring din skepsis – og lav din hjemmearbejde.

Ofte vil holdene invitere katastrofen ved at gå ind i cloud-arrangementer under antagelse af, at store cloud-virksomheder er indbygget pålidelige. Forvisso har de mest betroede virksomheder fortjent deres rygte af en grund. Samtidig tilbyder hver cloud og hyperscaler et bredt udvalg af infrastrukturmuligheder – AWS North America alene har 31 Tilgængelighedszoner og 31 Edge Network-placeringer – og nogle muligheder er langt mere pålidelige end andre.

Faktisk havde AWS’s US-EAST-1 Region, årsagen til denne uges afbrud, været bag store forstyrrelser i 2020, 2021 og 2023, og det var længe kendt i visse IT-kredse som den mindst pålidelige region. Mange virksomheder forstod sandsynligvis situationen, men tog en kalkuleret risiko på grund af regionens lave omkostninger og mange tilbud. Men givet omfanget af afbruddet er det umuligt ikke at overveje, hvor mange virksomheder blev fuldstændigt overrasket – og ville have valgt de mere pålidelige regioner, hvis de havde været bekendt med afvælgene. Jeg har personligt mødt IT-ledere, der valgte at flytte til andre AWS-regioner efter dårlige oplevelser med US-EAST-1 i fortiden.

Lektien her er at gøre din hjemmearbejde, når det kommer til cloud-infrastrukturmuligheder, uanset hvilken cloud du arbejder med. Steder at starte inkluderer gratisværktøjer som cloudprice, Cloudping og de historiske incidentvisninger fra hyperscaler-provided Cloud Service Health-værktøjer.

Vælg portable over cloud-native.

Når du designer cloud-konfigurationer, er den simpleste vej at gå cloud-native. Men selvom det er praktisk at vælge applikationer, der er klar til at blive bygget af og til din cloud-udbyder, efterlader disse cloud-native muligheder dig mere udsat, hvis din cloud går ned.

For at undgå den ekstra lag af cloud-afhængighed skal du vælge uafhængige og/eller open-source-produkter, hvor det er muligt. Nogle eksempler på erstatninger inkluderer følgende:

Forvisso betyder opbygning af mere af din cloud-stack fra bunden mere arbejde for dine hold. Men i min erfaring, når du først har infrastrukturen op og kørende, er der lille eller ingen forskel på at tilføje arbejdslast til en etableret hjemmegjort infrastruktur eller til at operere på en cloud-native en. Og fordelene i form af robusthed – ikke at nævne reduceret cloud-låsning – gør uafhængige muligheder meget værdifulde.

Ingeniør for fejl.

Givet, at cloud-fejl vil ske, skal du sørge for at designe dine produkter med cloud-fejl i mente. Et eksempel at se på er Datadog: i en 2023-episode, mistede virksomheden pludselig adgang til over halvdelen af sine Kubernetes-noder i produktion og genopbyggede fuldstændigt sin katastrofe-tilgang som svar. Ændringerne inkluderede fjernelse af arkitektoniske flaskeshals og håndtering af teknisk gæld, så partielle fejl ikke ville kaskade gennem systemet, forbedring af data-indtagelse og -lagring til større data-tilgængelighed under afbrud, og opbygning af systemer til automatisk genoprettelse i stor skala. Et godt sted at starte på din rejse er at følge Datadogs anbefaling til at “starte med, hvad der er vigtigt for slutbrugeren”, og bygge sikkerhedsforanstaltninger til at beskytte, hvad der betyder mest.

Kør på mindst to clouds.

Selvfølgelig er den bedste måde at undgå at være afhængig af cloud-fejl multicloud-redundans. At opnå sand multicloud-flydighed er en enorm opgave for mange virksomheder, da det er ekstremt svært at oversætte infrastruktur fra en cloud til en anden. Men opbygning af infrastruktur på bare to clouds er et stærkt – og ofte gennemførligt – sted at starte. Vigtigt for at gøre dette virker er at have et hold på plads med en ekspert i hver af de clouds, du kører på.

Forvisso kan intet fuldstændigt beskytte virksomheder mod impacten af et massivt afbrud som det, vi så denne uge. Men med den rette hjemmearbejde, en cloud-portable tilgang, ingeniør-arbejde for fejl og brug af “dual-cloud” som et springbræt til sand multicloud, kan virksomheder være langt mere agile, når det næste (og desværre uundgåelige) store cloud-episode rammer.