Connect with us

Tankeledere

Start forberedelsen nå for den neste sky-avbruddet

mm

Store sky-hendelser som denne uken fra AWS er uunngåelige. Disse fire metodene kan hjelpe din bedrift å komme gjennom.

Med talløse timer med tapt produktivitet, finansielle systemer forstyrret for millioner av brukere, og potensielt hundre milliarder dollar tapt, var denne uken AWS-avbruddet en ubestridt dårlig dag for globale IT-lag. Selvfølgelig var det også den verste globale sky-katastrofen siden den siste… og til den neste.

Uansett om du er på AWS, GCP, Azure eller en annen plattform, er store avbrudd en realitet i sky-computing. Hva kan din bedrift gjøre for å mildne slaget? Under vil jeg tilby fire trinn som ditt lag kan ta umiddelbart.

Bring din skepsis – og gjør din hjemmelekse.

Ofte vil lagene gå mot katastrofen ved å gå inn i sky-arrangementer med antakelsen om at store sky-selskaper er innebygget pålitelige. For å være sikker, har de mest pålitelige selskapene tjent sin rykte for en grunn. Samtidig tilbyr hver sky og hyperscaler en rekke infrastrukturvalg – AWS Nord-Amerika alene har 31 Tilgjengelighets-soner og 31 Edge Network-plasser – og noen valg er langt mer pålitelige enn andre.

I virkeligheten hadde AWS’s US-EAST-1 Region, årsaken til denne uken avbrudd, vært 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 rikelige tilbud. Men gitt omfanget av avbruddet, er det umulig å ikke vurdere hvor mange selskaper ble tatt fullstendig overrasket – og ville sikkert valgt de mer pålitelige regionene hvis de hadde vært klar over valget.

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 hyperscaler-provided Cloud Service Health-verktøy.

Velg portabelt over sky-nativt.

Når du designer sky-konfigurasjoner, er den enkleste veien å gå sky-nativt. Men mens det er praktisk å velge applikasjoner som er ferdigbygget av og for din sky-tilbyder, gjør disse sky-nativt valgene deg mer utsatt hvis din sky går ned.

For å unngå den ekstra lag av sky-avhengighet, velg uavhengige og/eller åpne kilde-produkter hvor mulig. Noen eksempler på erstattere inkluderer:

Kategori

Nativt tilbudseksempel

Åpne kilde-alternativer inkluderer…

Autentisering & Identitet

AWS Cognito

Keycloak

Søk

Azure Monitor

Elasticsearch

Relasjonelle databaser

Google Cloud SQL

PostgreSQL

NoSQL-databaser

AWS DynamoDB

MongoDB

Container-Orkestrering

Azure Kubernetes Service (AKS)

Kubernetes

Overvåking & Observasjon

Google Cloud Monitoring

Prometheus + Grafana

Meldingskøer

AWS SQS/SNS

Apache Kafka

Objekt-lagring

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 lag. Men i min erfaring, en gang du har infrastrukturen i drift, er det liten eller ingen forskjell på å legge til arbeidsbyrde til en etablert hjemmebygget infrastruktur eller å operere på en sky-nativ en. Og fordeler i form av motstandskraft – ikke til å nevne redusert sky-låsning – gjør uavhengige alternativer svært verdifulle.

Ingeniør for feil.

Gitt at sky-feil vil skje, sikre deg å designe dine produkter med sky-feil 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 redesignet sin katastrofe-tilnærming som respons. Endringer inkluderte fjerning av arkitektoniske flaskenakker og å håndtere teknisk gjeld så at delvis feil ikke ville skje gjennom systemet, forbedring av data-inntak og lagring for større data-tilgjengelighet under avbrudd, og bygging av systemer for å automatisk gjenopprette på skala. En god plass å starte på din reise er å følge Datadogs anbefaling om å “starte med hva som er viktig for sluttbrukeren”, og bygge sikkerhetsforanstaltninger for å beskytte hva som betyr mest.

Kjør på minst to skyer.

Selvfølgelig er den beste måten å ikke være avhengig av sky-feil multicloud-redundans. Å oppnå sanne multicloud-flytighet er en enorm 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 virke er å ha et lag på plass med en ekspert i hver av skyene du kjører på.

For å være sikker, kan ingenting skjerme selskaper fullstendig fra impakten av et massivt avbrudd som det vi så denne uken. Men med riktig hjemmelekse, en sky-portabel tilnærming, ingeniør for feil, og å bruke “dual-cloud” som en stegstein til sanne multicloud, kan selskaper være langt mer smidige når den neste (og dessverre uunngåelige) store sky-hendelsen inntreffer.

Harshit Omar er medgrunnlegger og CTO i FluidCloud, der han bygger fremtiden for skyinfrastruktur – og muliggjør at bedrifter kan flytte, replikere og optimere arbeidsbyrder på tvers av multi-sky-miljøer. Han var tidligere den første ingeniøren i Accurics, der han ledet kjerneutviklingsinnsatsene på sin politimotor og sky-sikkerhetsplattform.

Med dypt ekspertise i Go, Kubernetes, Terraform og sky-overholdelse, har Harshit brukt over et tiår på å designe resiliente systemer på tvers av AWS, Azure og GCP.

Hans misjon nå er å eliminere sky-lås og gjøre infrastruktur like portabel og resilient som kode.