Varför din e-handelsplats behöver en aktiv-aktiv multi-molntjänst i jul

För e-handelsledare medför julen två säkerheter: en massiv tillströmning av shoppare och en ökad risk för molntjänstleverantörsavbrott. Stora molnavbrott verkar bli vanligare och mer förödande. AWS US-East-1-regionen har till exempel en historia av betydande julavbrott. Likaså har Microsoft Azure varje år runt januari nätverksfördröjningar eller nätverksavbrott på grund av deras utgivnings- eller testplan i vissa regioner. Och vi behöver bara se tillbaka till juni förra året, när ett stort Google Cloud-avbrott påverkade en stor mängd applikationer, för att påminnas om att ingen enskild leverantör är immun.

Om du är ansvarig för en e-handelsverksamhet vill du inte upptäcka att även om du har allt korrekt inställt, så har något slutat fungera under det mest kritiska tillfället på året. Dessa molntjänstleverantörsavbrotts- och problemtrender kanske inte är på din radar, och ärligt talat, borde de inte vara det. Om du är en systemansvarig ingenjör, borde du inte behöva oroa dig för om ett molntjänstleverantörsavbrott kommer att påverka din applikation, och du borde inte försöka justera din infrastruktur på flyget under ett problem. Istället borde du omvärdera vad du vet om multi-moln.

Multi-molnapplikationer

Om din organisation betalar för AWS-, Azure- och GCP-avgifter, så har du verkligen alla tre moln till ditt förfogande. Det sagt, medan du kan använda alla tre, är det viktigt att undersöka vad som händer när du går ett lager djupare. Är vissa av dina applikationer specifika för AWS, Azure eller GCP? Kommer de att fortsätta fungera om en molntjänstleverantör är nere och du behöver snabbt växla till en annan?

Din applikation måste fungera perfekt på valfri molntjänst. Det är vad en sann multi-molnkonfiguration är. Om du vill vara molnagnostisk, kan du inte bara betala för multi-moln, du måste också se till att dina applikationer är multi-moln.

Dessutom introducerar beroende av en enskild leverantör inbyggda begränsningar för beräkningskapacitet, API-hastighetsbegränsning och regional tillgänglighet. En sann multi-molnarkitektur ökar din sammanlagda beräkningskraft och ger motståndskraft mot dessa begränsningar. Den låser upp din förmåga att skala på begäran bortom en enskild leverantörs gränser, expandera kapacitet snabbt över geografier och säkerställa konsekvent prestanda under topphandelsdagar. Men att ha en portabel, molnagnostisk applikation är bara det första steget, nästa är att distribuera den i en sann motståndskraftig arkitektur.

Skalning till en aktiv-aktiv approach

Detta kräver en del allvarlig förberedelse av DevOps. Det är otroligt svårt att ha en 100% korrekt Business Continuity Disaster Recovery (BCDR)-strategi eftersom när det gäller att köra dina operationer live, finns det flera felkällor. Du vill inte testa din BCDR-strategi under ett avbrott, så du kan känna att allt du kan göra är att förutsäga möjliga scenarier och sedan förbereda dig därefter.

Min råd till systemansvariga ingenjörer är att arkitektera för fel som standard. Det innebär att ha en sekundär eller till och med en tertiär molntjänst som körs i en aktiv tillstånd. En BCDR-strategi som är begränsad till en enskild leverantör är en enskild felkälla, om leverantörens kontrollplan eller nätverksryggrad misslyckas, så är hela din återhämtning plan förstörd.

Under julen är det vanligt att antalet besökare plötsligt ökar, vilket tvingar din plattform eller applikation att börja fungera med reducerad kapacitet. Om du redan har skapat en kopia av din fungerande applikation, en sekundär, kan du växla till att utföra lastbalansering så att du kan dirigera vissa förfrågningar till den andra instansen av din applikation.

Denna aktiv-aktiv tillvägagångssätt innebär att du har din fullständiga produkt duplicerad, som körs någon annanstans. Om din primära molntjänstleverantör upplever ett allvarligt försämring eller avbrott, kan du sömlöst flytta 100% av din trafik till den sekundära leverantören via DNS eller en global lastbalanserare, vilket gör det till den primära ingångspunkten utan avbrott för dina kunder.

Den verkliga kostnaden för att inte gå multi-moln

Medan kostnaden för att köra en sekundär molntjänst inte är försumbar, är den obetydlig jämfört med den affärsmässiga påverkan av ett stort avbrott: att be om ursäkt till kunder efter ett tillförlitlighetsfel, försöka övertyga dem om att det inte kommer att hända igen och övertyga dem om att inte lämna dig för en av dina konkurrenter. Låt oss inte heller glömma all den förlorade intäkten från de förlorade försäljningarna som du inte kan vinna tillbaka. På FluidCloud har jag sett denna scenarie spela ut gång på gång: företag investerar tungt i en enskild leverantör, bara för att upptäcka att de är på fel sida om ett avbrott utan omedelbar återgång.

Det sagt, är det svårt nog att kontrollera dina kostnader om du bara använder en molntjänstleverantör, dina molnkostnader ser förmodligen ut som en exponentiell graf. Om du antar flera moln, kommer den exponentiella grafen att se ännu brantare ut.

När du dubblerar din infrastruktur från din primära molntjänst, vill du naturligtvis inte att dina kostnader ska fördubblas. Jag rekommenderar därför att fokusera på billigare moln som erbjuder konkurrenskraftig prestanda till ett lägre pris. Om du har en sekundär som körs i ett billigare moln, kommer du fortfarande att ha full aktiv-aktiv redundans, men till en lägre kostnad. Det är en vinst-vinst.

Slutliga tankar

Att köra dina applikationer aktiv-aktiv över flera molntjänstleverantörer innebär inte bara att skapa en säkerhetskopia. Det innebär att bygga för realtidsmotståndskraft, säkerställa att din verksamhet inte har en enskild felkälla och kunna erbjuda konsekvent hastighet även under trafiktoppar.

Denna jul, hoppas inte bara på tillförlitlighet. Bygg för det. Utforma dina system för att köra konsekvent, oavsett vilken molntjänstleverantör eller region som sviktar. Erbjuda en fläckfri kundupplevelse genom att anta en sann aktiv-aktiv, multi-molnarkitektur.