Waarom uw e-commerce-site een actief-actieve multi-cloud-aanpak nodig heeft deze feestdagen

Voor e-commerce-leiders brengen de feestdagen twee zekerheden met zich mee: een enorme toestroom van shoppers en een verhoogd risico op storingen van cloudproviders. Grote cloudonderbrekingen lijken vaker voor te komen en zijn steeds verwoestender. De AWS US-East-1-regio heeft bijvoorbeeld een geschiedenis van significante storingen tijdens de feestdagen. Evenzo heeft Microsoft Azure elk jaar rond januari netwerkvertragingen of -storingen vanwege hun release- of testplan in bepaalde regio’s. En we hoeven alleen maar terug te kijken naar juni, toen een grote storing van Google Cloud een breed scala aan toepassingen trof, om ons te herinneren dat geen enkele provider immuun is.

Als u verantwoordelijk bent voor een e-commerce-operatie, wilt u niet ontdekken dat, zelfs als u alles correct hebt ingesteld, er iets niet werkt tijdens de meest kritieke tijd van het jaar. Deze trends van storingen en problemen van cloudproviders hoeven niet op uw radar te staan, en eigenlijk zouden ze dat ook niet moeten zijn. Als u een site reliability engineer bent, zou u zich geen zorgen moeten maken over het feit of een storing van een cloudplatform uw toepassing zal beïnvloeden, noch zou u proberen uw infrastructuur aan te passen tijdens een storing. In plaats daarvan moet u uw kennis over multi-cloud opnieuw evalueren.

Multi-cloud-toepassingen

Als uw organisatie AWS-, Azure- en GCP-kosten betaalt, heeft u inderdaad alle drie de clouds tot uw beschikking. Dat gezegd hebbende, terwijl u mogelijk alle drie gebruikt, is het belangrijk om te onderzoeken wat er gebeurt wanneer u een laag dieper gaat. Zijn sommige van uw toepassingen specifiek voor AWS, Azure of GCP? Zullen ze blijven werken als een cloudprovider uitvalt en u snel moet overschakelen naar een andere?

Uw toepassing moet perfect werken op elke van de clouds. Dat is wat een echte multi-cloud-opstelling is. Als u cloud-agnostisch wilt zijn, kunt u niet alleen voor multi-cloud betalen; u moet er ook voor zorgen dat uw toepassingen multi-cloud zijn.

Bovendien introduceert het vertrouwen op één provider inherente beperkingen op compute-capaciteit, API-limiet en regionale beschikbaarheid. Een echte multi-cloud-architectuur verhoogt uw totale compute-kracht en biedt weerstand tegen deze beperkingen. Het ontgrendelt uw vermogen om op aanvraag te schalen, om snel capaciteit uit te breiden over geografische gebieden en om consistent te presteren tijdens piekdagen. Maar een portable, cloud-agnostische toepassing is alleen de eerste stap; de volgende stap is het implementeren ervan in een echt robuuste architectuur.

Schalen naar een actief-actieve aanpak

Dit vereist enige serieuze voorbereiding door DevOps. Het is ontzettend moeilijk om een 100% nauwkeurige Business Continuity Disaster Recovery (BCDR)-strategie te hebben, omdat er bij het uitvoeren van uw operaties live meerdere punten van falen zijn. U wilt uw BCDR-strategie niet testen tijdens een storing, dus u voelt misschien dat u alleen maar mogelijke scenario’s kunt voorspellen en zich daarop voorbereiden.

Mijn advies aan site reliability engineers is om te ontwerpen voor falen per default. Dit betekent dat u een secundaire of zelfs tertiaire cloud in een actieve staat hebt draaien. Een BCDR-strategie die beperkt is tot één provider is een enkel punt van falen; als de provider zijn controlevlak of netwerkbackbone faalt, is uw hele herstelplan nutteloos.

Tijdens de feestdagen is het gebruikelijk dat het aantal bezoekers plotseling toeneemt, waardoor uw platform of toepassing moet beginnen met een verminderde capaciteit. Als u al een kopie van uw werkende toepassing hebt gemaakt, een secundaire, kunt u overschakelen naar load balancing, zodat u sommige verzoeken naar de andere instantie van uw toepassing kunt omleiden.

Deze actief-actieve aanpak betekent dat u uw complete product hebt gedupliceerd en elders draait. Als uw primaire cloudprovider een ernstige degradatie of storing ondervindt, kunt u 100% van uw verkeer naadloos omleiden naar de secundaire provider via DNS of een globale load balancer, waardoor deze de primaire toegangspunt wordt zonder enige onderbreking voor uw klanten.

De echte kosten van het niet kiezen voor multi-cloud

Hoewel de kosten van het draaien van een secundaire cloud niet triviaal zijn, zijn ze verwaarloosbaar in vergelijking met de bedrijfsimpact van een grote storing: excuses aanbieden aan klanten na een storing, proberen hen ervan te overtuigen dat het niet weer zal gebeuren en hen proberen te weerhouden van overstappen naar een van uw concurrenten. Laten we ook niet vergeten alle gemiste omzet van de verloren verkoop die u niet terug kunt winnen. Bij FluidCloud heb ik dit scenario keer op keer zien gebeuren: bedrijven investeren zwaar in één provider, alleen om zichzelf aan de verkeerde kant van een storing te vinden zonder enige onmiddellijke mogelijkheid tot herstel.

Dat gezegd hebbende, is het moeilijk genoeg om uw kosten onder controle te houden als u alleen één cloudprovider gebruikt; uw cloudkosten zien er waarschijnlijk uit als een exponentiële grafiek. Als u meerdere clouds adopteert, zal die exponentiële grafiek er alleen maar steiler uitzien.

Wanneer u uw infrastructuur dupliceert van uw primaire cloud, wilt u natuurlijk niet dat uw kosten verdubbelen. Ik raad daarom aan om goedkopere clouds te kiezen die concurrerende prestaties bieden tegen een lagere prijs. Als u een secundaire cloud draait in een goedkopere cloud, hebt u nog steeds volledige actief-actieve redundantie, maar tegen een lagere prijs. Het is een win-winsituatie.

Laatste gedachten

Het draaien van uw toepassingen actief-actief over meerdere cloudproviders betekent niet alleen het maken van een back-up. Het betekent het bouwen van echte tijd-resilientie, het waarborgen dat uw bedrijf geen enkel punt van falen heeft en het kunnen bieden van consistentie in snelheid, zelfs tijdens verkeerspieken.

Deze feestdagen, hoop niet alleen op betrouwbaarheid. Bouw erop. Ontwerp uw systemen om consistent te draaien, ongeacht welke cloudprovider of regio faalt. Lever een perfecte klantbeleving door een echte actief-actieve, multi-cloud-architectuur te omarmen.