Hvorfor dit e-commerce-websted har brug for en aktiv-aktiv multi-cloud-tilgang denne ferie-sæson

For e-commerce-ledere bringer ferien to sikre ting: en massiv tilstrømning af kunder og en højere risiko for cloud-udbyder-afbrud. Store cloud-forstyrrelser synes at blive mere almindelige og mere ødelæggende. AWS US-East-1-regionen har for eksempel en historie med betydelige ferie-sæson-forstyrrelser. Ligesom hvert år omkring januar, har Microsoft Azure tendens til at have netværksforsinkelser eller netværksafbrud på grund af deres udgivelses- eller testplan i visse regioner. Og vi behøver kun at se tilbage på sidste juni, da en stor Google Cloud-afbrud påvirkede en bred vifte af applikationer, for at blive mindet om, at ingen enkelt udbyder er immun.

Hvis du er ansvarlig for en e-commerce-drift, ønsker du ikke at opdage, at selvom du har alt sat op korrekt, er noget stoppet med at fungere under den mest kritiske tid på året. Disse cloud-udbyder-afbrud- og -problemtendenser kan måske ikke være på din radar, og ærligt talt, burde de ikke være det. Hvis du er en site-reliability-ingeniør, burde du ikke behøve at bekymre dig om, hvorvidt et cloud-platform-afbrud vil påvirke din applikation, eller om du skal forsøge at justere din infrastruktur på flyvende fod under et problem. I stedet burde du se nærmere på, hvad du ved om multi-cloud.

Multi-cloud-applikationer

Hvis din organisation betaler AWS-, Azure- og GCP-gebyrer, har du faktisk alle tre cloud-udbydere til rådighed. Det sagde, selvom du måske bruger alle tre, er det vigtigt at se på, hvad der sker, når du går et lag dybere. Er nogle af dine applikationer AWS-, Azure- eller GCP-specifikke? Vil de fortsætte med at fungere, hvis en cloud-udbyder er nede, og du hurtigt skal skifte til en anden?

Din applikation må fungere perfekt på enhver af cloud-udbyderne. Det er, hvad en sand multi-cloud-opstilling er. Hvis du ønsker at være cloud-agnostisk, kan du ikke bare betale for multi-cloud; du må også sikre, at dine applikationer er multi-cloud.

Desuden introducerer afhængighed af en enkelt udbyder indbyggede begrænsninger på beregningskapacitet, API-hastighedsbegrænsning og regional tilgængelighed. En sand multi-cloud-arkitektur øger din samlede beregningskraft og giver modstandskraft mod disse begrænsninger. Den låser op for din evne til at skala på krav ud over begrænsningerne for en enkelt udbyder, hurtigt udvide kapacitet på tværs af geografier og sikre konstant ydeevne under peak-shoppingsdage. Men at have en bærbar, cloud-agnostisk applikation er kun det første skridt; det næste er at installere den i en virkelig resilient arkitektur.

Skalering til en aktiv-aktiv-tilgang

Dette kræver noget seriøst forberedelse af DevOps. Det er utrolig svært at have en 100% præcis Business Continuity Disaster Recovery (BCDR)-strategi, da der, når det kommer til at køre dine operationer live, er multiple fejlpoint. Du ønsker ikke at teste din BCDR-strategi under et afbrud, så du måske føler, at alt, du kan gøre, er at forudsige mulige scenarier og derefter forberede dig derefter.

Min råd til site-reliability-ingeniører er at arkitektere for fejl som standard. Dette indebærer at have en sekundær eller endda en tertiær cloud, der kører i en aktiv tilstand. En BCDR-strategi, der er begrænset til en enkelt udbyder, er et enkelt fejlpoint; hvis udbyderens kontrolplan eller netværksryggrad fejler, er hele din genoprettelsesplan værdiløs.

Under ferie-sæsonen er det almindeligt, at antallet af besøgende pludselig øges, hvilket tvinger din platform eller applikation til at starte med at fungere med reduceret kapacitet. Hvis du allerede har oprettet en kopi af din fungerende applikation, en sekundær, kan du skifte til at udføre belastningsfordeling, så du kan omdirigere nogle anmodninger til den anden instans af din applikation.

Denne aktiv-aktiv-tilgang betyder, at du har din fuldt udbyggede produkt duplikeret, der kører et andet sted. Hvis din primære cloud-udbyder oplever en alvorlig forringelse eller afbrud, kan du uden problemer flytte 100% af din trafik til den sekundære udbyder via DNS eller en global belastningsfordeler, hvilket gør det til det primære indgangspunkt uden afbrydelse af dine kunder.

Den virkelige omkostning ved ikke at gå multi-cloud

Selvom omkostningerne ved at køre en sekundær cloud ikke er ubetydelige, er de ubetydelige i forhold til den forretningsmæssige påvirkning af et større afbrud: at undskuldende sig over for kunder efter et tillidsbrud, forsøge at forsikre dem om, at det ikke vil ske igen, og overbevise dem om ikke at forlade dig for en af dine konkurrenter. Lad os ikke glemme alle de tabte indtægter fra de tabte salg, du ikke kan vinde tilbage. Hos FluidCloud har jeg set denne situation udspille sig gang på gang: virksomheder investerer massivt i en enkelt udbyder, blot for at opdage, at de er på den forkerte side af et afbrud med ingen umiddelbar løsning.

Det sagde, er det svært nok at kontrollere dine omkostninger, hvis du kun bruger en enkelt cloud-udbyder; dine cloud-omkostninger ligner sandsynligvis en eksponentiel graf. Hvis du adopterer multiple cloud-udbydere, vil denne eksponentielle graf blot se endnu stejlere ud.

Når du duplikerer din infrastruktur fra din primære cloud, ønsker du naturligvis ikke, at dine omkostninger skal fordobles. Jeg anbefaler derfor at fokusere på billigere cloud-udbydere, der tilbyder konkurrencedygtig ydeevne til en lavere pris. Hvis du har en sekundær, der kører i en billigere cloud, har du stadig fuld aktiv-aktiv reserve, men til en lavere pris. Det er en gevinst-gévinst.

Endelige tanker

At køre dine applikationer aktiv-aktiv på tværs af multiple cloud-udbydere betyder ikke bare at oprette en reserve. Det betyder at bygge for realtids-resiliens, sikre, at din forretning ikke har et enkelt fejlpoint, og være i stand til at tilbyde konstant hastighed, selv under trafiktoppe.

Denne ferie-sæson, håb ikke bare på tillid. Byg for det. Ingeniør dine systemer til at køre konstant, uanset hvilken cloud-udbyder eller region, der svigter. Lever en fejlfri kundeoplevelse ved at omfavne en sand aktiv-aktiv, multi-cloud-arkitektur.