Miksi verkkokauppasivustollasi tarvitaan aktiivis-aktiivinen monipilviarkkitehtuuri tämän joulukauden aikana

Verkkokaupan johtajille joulu tuo kaksi varmuutta: valtavan ostosvyöryn ja pilvipalveluntarjoajien katkojen riskin. Suuret pilvipalveluhäiriöt näyttävät yleistymisen ja heikentymisen. Esimerkiksi AWS US-East-1 -alueella on ollut historia merkittävistä joulukausimittaisista häiriöistä. Samoin joka vuosi tammikuun aikana, Microsoft Azurella on ollut verkkovälimuistin viiveongelmia tai verkkokatkoja tietyillä alueilla sen julkaisu- tai testausjärjestelyjen vuoksi. Ja meidän tarvitsee vain katsoa takaisin viime kesäkuuhun, jolloin suuri Google Cloud -häiriö vaikutti laajaan joukkoon sovelluksiin, muistuttaaksemme, että yksikään tarjoajaa ei ole immuuni.

Jos olet vastuussa verkkokaupasta, et halua kuulla, että vaikka olet asettanut kaiken oikein, jokin on lopettanut toimintansa joulukauden kriittisimmän ajan. Nämä pilvipalveluntarjoajien häiriö- ja ongelmatrendit eivät välttämättä ole radarissasi, ja rehellisesti sanottuna, niiden ei pitäisi olla. Jos olet sivuston luotettavuusinsinööri, et pidä huolehtia siitä, vaikuttaako pilvipalvelualustan häiriö sovellukseesi, eikä sinun pidä yrittää sopeuttaa infrastruktuuria lennossa häiriön aikana. Sen sijaan sinun pitäisi tarkastella uudelleen, mitä tiedät monipilvestä.

Monipilvisovellukset

Jos organisaatiosi maksaa AWS:lle, Azurelle ja GCP:lle, sinulla on todella käytettävissäsi kaikki kolme pilveä. Sanottakoon, että vaikka käytät kaikkia kolmea, on tärkeää tarkastella, mitä tapahtuu, kun menet yhden kerroksen syvemmälle. Onko joitakin sovelluksiasi, jotka ovat AWS-, Azure- tai GCP-kohtaisia? Toimivatko ne edelleen, jos yksi pilvipalvelu on poissa käytöstä ja sinun on nopeasti vaihdettava toiseen?

Sovelluksesi on toimittava täydellisesti missä tahansa pilvessä. Se on todellinen monipilvi-asettelu. Jos haluat olla pilvi-agnostinen, et voi vain maksaa monipilvestä; sinun on varmistettava, että sovelluksesi ovat myös monipilvi.

Lisäksi yhden tarjoajan käyttäminen tuo mukanaan sisäisiä rajoituksia laskentakapasiteetissa, API-väylärajoituksissa ja alueellisessa saatavuudessa. Todellinen monipilviarkkitehtuuri lisää yhteistä laskentavoimaa ja tarjoaa kestävyyttä näiden rajoitusten vastaisesti. Se avaa kykysi skaalata tarpeen mukaan yhden tarjoajan rajoitusten yli, laajentaa nopeasti kapasiteettia eri maantieteellisillä alueilla ja varmistaa johdonmukaisen suorituskyvyn huippukausina. Mutta siirrettävän, pilvi-agnostisen sovelluksen omistaminen on vain ensimmäinen askel; seuraava on sen käyttöönotto todella kestävässä arkkitehtuurissa.

Skaalautuminen aktiivis-aktiiviseen lähestymistapaan

Tämä vaatii vakavasti DevOpsin valmistautumista. On erittäin vaikea saavuttaa 100 %:n tarkka liiketoiminnan jatkuvuuden ja häiriönhallinnan strategia, koska kun suoritat toimintaa livenä, on useita kohtia, joissa voi esiintyä virheitä. Et halua testata BCDR-strategiaasi häiriön aikana, joten sinun täytyy ehkä tuntea, että voit vain ennustaa mahdollisia skenaarioita ja sitten valmistautua sen mukaan.

Neuvoni sivuston luotettavuusinsinööreille on suunnitella virheille oletusarvoisesti. Tämä tarkoittaa toissijaisen tai jopa kolmannen pilven käyttöä aktiivisessa tilassa. Yksittäisen tarjoajan BCDR-strategia on yksittäinen virhekohta; jos tarjoajan ohjaus- tai verkkotukirunko epäonnistuu, koko palautusstrategia on turvaton.

Joulukauden aikana on yleistä, että vierailijoiden määrä kasvaa äkkiä, minkä seurauksena alustasi tai sovelluksesi on aloitettava toiminta vähennetyllä kapasiteetilla. Jos olet jo luonut toimivan sovelluksesi kopion, toissijaisen, voit siirtyä kuormituksen tasapainottamiseen, jotta voit ohjata osan pyynnöistä sovelluksesi toiseen instanssiin.

Tämä aktiivis-aktiivinen lähestymistapa tarkoittaa, että sinulla on koko tuotteesi monistettuna ja toiminnassa jossakin muualla. Jos ensisijainen pilvipalveluntarjoajasi kokee vakavan heikentymisen tai häiriön, voit siirtää 100 % liikenteestäsi toissijaiseen tarjoajaan DNS:n tai globaalin kuormituksen tasapainottamisen kautta ilman, että se vaikuttaa asiakkaisiin.

Monipilven käyttämättä jättämisen todellinen kustannus

Vaikka toissijaisen pilven käyttäminen ei ole vähäinen kustannus, se on merkityksettömänä verrattuna liiketoiminnan vaikutuksiin suuresta häiriöstä: anteeksipyytäminen asiakkailta luotettavuuden epäonnistumisen jälkeen, yrittäminen vakuuttaa heille, että se ei toistu, ja yrittäminen vakuuttaa heille, etteivät he jätä sinua kilpailijoidesi vuoksi. Älkäämme unohda kaikkia menetettyjä myyntituloksia, joita et voi voittaa takaisin. FluidCloudissa olen nähnyt tämän skenaarion toistuvan useasti: yritykset investoivat suuria summia yhteen tarjoajaan, vain löytääkseen itsensä väärällä puolella häiriöstä ilman välitöntä apua.

Sanottakoon, että on riittävän vaikeaa hallita kustannuksia, kun käytät vain yhtä pilvipalveluntarjoajaa; pilvikustannukset muistuttavat todennäköisesti eksponentiaalista kaavaa. Kun otat käyttöön useita pilviä, tuo eksponentiaalinen kaava tulee vain näyttämään jyrkemmältä.

Kun kopioit infrastruktuurisi ensisijaisesta pilvestä, et luonnollisesti halua, että kustannukset kaksinkertaistuvat. Suosittelen tämän vuoksi keskittymistä edullisempiin pilviin, jotka tarjoavat kilpailevaa suorituskykyä edullisemalla hinnalla. Jos sinulla on toissijainen toiminnassa edullisemmassa pilvessä, sinulla on edelleen täysi aktiivis-aktiivinen redundanssi, mutta edullisemalla hinnalla. Se on voitto-voitto.

Loppusanat

Sovellustesi suorittaminen aktiivis-aktiivisena useiden pilvipalveluntarjoajien yli ei tarkoita pelkästään varmuuskopion luomista. Se tarkoittaa rakentamista reaaliaikaisen kestävyyden vuoksi, varmistamista, ettei liiketoiminnallasi ole yksittäistä virhettä, ja kykyä tarjota johdonmukaista nopeutta liikenteen huippukausina.

Tämä joulu, älä toivo vain luotettavuutta. Rakenna sille. Suunnittele järjestelmiäsi toimimaan johdonmukaisesti, riippumatta siitä, mikä pilvipalveluntarjoaja tai alue epäonnistuu. Tarjoa virheetön asiakaskokemus omaksumalla todellisen aktiivis-aktiivisen monipilviarkkitehtuurin.