Hvorfor din e-handelsnettsted trenger en aktiv-aktiv multi-sky-tilnærming denne høytiden

For e-handelsledere bringer høytiden to sannheter: en massiv tilstrømning av kjøpere og en høy risiko for sky-tilbyderens avbrudd. Store sky-forstyrrelser ser ut til å bli mer vanlige og mer ødeleggende. AWS US-East-1-regionen, for eksempel, har en historie med betydelige høytide-avbrudd. Liksom hvert år rundt januar, har Microsoft Azure tendens til å ha nettverksforsinkelser eller nettverksavbrudd på grunn av deres utgivelses- eller testplan i visse regioner. Og vi trenger bare å se tilbake til juni i fjor, da en større Google Cloud-avbrudd påvirkte en rekke applikasjoner, for å bli påminnet om at ingen enkelt tilbyder er immun.

Hvis du er ansvarlig for en e-handelsdrift, ønsker du ikke å oppdage at selv om du har alt satt opp korrekt, har noe stoppet med å fungere under den mest kritiske tiden av året. Disse sky-tilbyderens avbrudds- og problem-trendene kan kanskje ikke være på din radar, og ærlig talt, burde de ikke være det. Hvis du er en systemansvarlig ingeniør, burde du ikke være bekymret for om en sky-plattform-avbrudd vil påvirke din applikasjon, og du burde ikke prøve å justere din infrastruktur på fly under et problem. I stedet burde du se på hva du vet om multi-sky.

Multi-sky-applikasjoner

Hvis din organisasjon betaler AWS-, Azure- og GCP-gebyrer, har du faktisk alle tre skyer til disposisjon. Det sagt, mens du kanskje bruker alle tre, er det viktig å se på hva som skjer når du går ett lag dyptere. Er noen av dine applikasjoner AWS-, Azure- eller GCP-spesifikke? Vil de fortsatt fungere hvis en sky-tilbyder er nede og du må raskt bytte til en annen?

Din applikasjon må fungere perfekt på noen av skyene. Det er hva en sann multi-sky-oppsetting er. Hvis du ønsker å være sky-agnostisk, kan du ikke bare betale for multi-sky; du må også sikre at dine applikasjoner er multi-sky.

Videre introduserer avhengighet av en enkelt tilbyder innebygde begrensninger på beregningskapasitet, API-hastighetsbegrensning og regional tilgjengelighet. En sann multi-sky-arkitektur øker din samlede beregningskraft og gir motstandskraft mot disse begrensningene. Den låser opp din evne til å skalerer på forespørsel utenfor grensene for en enkelt tilbyder, raskt utvide kapasitet over geografier og sikre konsekvent ytelse under topp handelsdager. Men å ha en bærbar, sky-agnostisk applikasjon er bare det første steget; det neste er å deployere den i en sann motstandskraftig arkitektur.

Skalering til en aktiv-aktiv-tilnærming

Dette krever en del alvorlig forberedelse fra DevOps. Det er usedvanlig vanskelig å ha en 100% nøyaktig Business Continuity Disaster Recovery (BCDR)-strategi siden når det kommer til å kjøre dine operasjoner live, er det flere feilpunkter. Du ønsker ikke å teste din BCDR-strategi under et avbrudd, så du kan føle at alt du kan gjøre er å forutsi mulige scenarier og deretter forberede deg i henhold til.

Min råd til systemansvarlige ingeniører er å arkitektere for feil som standard. Dette betyr å ha en sekundær eller til og med en tertiær sky som kjører i en aktiv tilstand. En BCDR-strategi begrenset til en enkelt tilbyder er et enkelt feilpunkt; hvis tilbyderens kontrollplan eller nettverksryggrad feiler, er hele din gjenopprettingsplan gjort ubrukelig.

Under høytiden er det vanlig at antallet besøkende plutselig øker, og tvinger din plattform eller applikasjon til å begynne å fungere med redusert kapasitet. Hvis du allerede har laget en kopi av din fungerende applikasjon, en sekundær, kan du bytte til å utføre lastbalansering så du kan divertere noen forespørsler til den andre instansen av din applikasjon.

Denne aktiv-aktiv-tilnærmingen betyr at du har din fullstendige produkt duplisert, kjørende et annet sted. Hvis din primære sky-tilbyder opplever en alvorlig forverring eller avbrudd, kan du sømløst flytte 100% av din trafikk til den sekundære tilbyder via DNS eller en global lastbalanser, og gjøre det til det primære inngangspunktet uten avbrudd for dine kunder.

Den virkelige kostnaden av ikke å gå multi-sky

Selv om kostnaden av å kjøre en sekundær sky ikke er ubetydelig, er den ubetydelig sammenlignet med forretningspåvirkningen av et større avbrudd: å unnskylde til kunder etter en pålitelighetsfeil, forsøke å forsikre dem om at det ikke vil skje igjen, og overbevise dem om ikke å forlate deg for en av dine konkurrenter. La oss også ikke glemme all den tapte inntekten fra de tapte salgene du ikke kan vinne tilbake. Hos FluidCloud har jeg sett denne scenariet spille ut gang på gang: selskaper investerer tungt i en enkelt tilbyder, bare for å finne seg på feil side av et avbrudd uten umiddelbar gjennomføring.

Det sagt, er det vanskelig nok å kontrollere dine kostnader hvis du bare bruker en sky-tilbyder; dine sky-kostnader ser sannsynligvis ut som en eksponentiell graf. Hvis du adopterer flere skyer, vil den eksponentielle grafen bare se ut til å bli enda brattere.

Når du dupliserer din infrastruktur fra din primære sky, ønsker du naturligvis ikke at dine kostnader skal dobles. Jeg anbefaler derfor å fokusere på billigere skyer som tilbyr konkurrerende ytelse til en lavere pris. Hvis du har en sekundær som kjører i en billigere sky, vil du fortsatt ha full aktiv-aktiv reserve, men til en lavere kostnad. Det er en gevinst-gjevinst.

Slutt tanker

Å kjøre dine applikasjoner aktiv-aktiv på flere sky-tilbydere betyr ikke bare å lage en reservekopi. Det betyr å bygge for sanntids-motstandskraft, sikre at din forretning ikke har et enkelt feilpunkt, og å kunne tilby konsekvent hastighet selv under trafikk-topper.

Denne høytiden, håper du ikke bare på pålitelighet. Bygg for det. Ingeniør dine systemer til å kjøre konsekvent, uansett hvilken sky-tilbyder eller region som svikter. Leverer en feilfri kundeopplevelse ved å omfavne en sann aktiv-aktiv, multi-sky-arkitektur.