Start forberedelsen nu til det næste cloud-udfald

Store cloud-ulykker som den, vi så denne uge, er uundgåelige. Disse fire metoder kan hjælpe dit firma med at mindske skaden.

Med utallige timer med tabt produktivitet, finansielle systemer, der er blevet afbrudt for millioner af brugere, og potentielt hundredvis af milliarder dollars tabt, var denne uges AWS-udfald 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 udfald en given del af cloud-computing-reality. Så hvad kan dit firma gøre for at mindske skaden? Herunder vil jeg give fire trin, som dit hold kan tage med det samme.

Bring din skepsis – og lav dine lektier.

Ofte vil holdene gå mod katastrofen ved at gå ind i cloud-aftaler med den antagelse, at store cloud-virksomheder er indiskutabelt pålidelige. For at være sikker har de mest troværdige virksomheder fortjent deres rygte af en god grund. Samtidig tilbyder hver cloud og hyperscaler et bredt udvalg af infrastrukturmuligheder – AWS North America alene har 31 Availability Zones og 31 Edge Network Locations – og nogle muligheder er langt mere pålidelige end andre.

Faktisk havde AWS’s US-EAST-1 Region, som var årsagen til denne uges udfald, været bagved 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 udfaldet 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 kompromiserne. Jeg har personligt mødt IT-ledere, som valgte at flytte til andre AWS-regioner efter dårlige oplevelser med US-EAST-1 i fortiden.

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

Vælg portable over cloud-native.

Når du designer cloud-konfigurationer, er den enkleste vej at gå cloud-native. Men selvom det er bekvemt at vælge applikationer, der er bygget af og til din cloud-leverandør, 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 dem nedenfor:

For at være sikker betyder det at bygge mere af din cloud-stack fra bunden at der er mere arbejde for dine hold. Men i min erfaring, når du først har infrastrukturen op og kørende, er der lidt eller intet forskel på at tilføje arbejdslast til en etableret hjemmebygget 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 højst værdifulde.

Konstruer 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 flaskehalse og adresse teknisk gæld, så partial fejl ikke ville kaskade gennem systemet, forbedring af data-indtagelse og -lagring til større data-tilgængelighed under udfald, og bygning 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 skyer.

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 at bygge infrastruktur på kun to skyer er et stærkt – og ofte gennemførligt – sted at starte. Kritisk for at gøre dette arbejde er at have et hold på plads med en ekspert i hver af de skyer, du kører på.

For at være sikker kan intet skærme virksomheder fuldstændigt fra effekten af et massivt udfald som det, vi så denne uge. Men med den rette due diligence, en cloud-portable tilgang, konstruktion for fejl og brug af “dual-cloud” som et skridt til sand multicloud, kan virksomheder være langt mere agile, når det næste (og desværre uundgåelige) store cloud-episode rammer.