Begin nu met voorbereiden op de volgende cloud-storing

Grote cloud-incidenten zoals deze week bij AWS zijn onvermijdelijk. Deze vier methoden kunnen uw bedrijf helpen om door te gaan.

Met ontelbare uren verloren productiviteit, financiële systemen verstoord voor miljoenen gebruikers, en mogelijk honderden miljarden dollars verloren, was de storing van AWS deze week een ongetwijfeld verschrikkelijke dag voor wereldwijde IT-teams. Natuurlijk was het ook de ergste wereldwijde cloud-ramp sinds de vorige… en tot de volgende.

Of u nu op AWS, GCP, Azure of een andere platform zit, grote storingen zijn een gegeven van de cloud-reality. Wat kan uw bedrijf dus doen om de klap te verzachten? Hieronder zal ik vier stappen noemen die uw team onmiddellijk kan nemen.

Breng uw scepsis mee – en doe uw huiswerk.

Vaak lopen teams het gevaar om een ramp te riskeren door cloud-regelingen te betreden met de veronderstelling dat grote cloud-bedrijven inherent betrouwbaar zijn. Om zeker te zijn, hebben de meest vertrouwde bedrijven hun reputatie voor een reden verdiend. Tegelijkertijd biedt elke cloud en hyperscaler een breed scala aan infrastructuur-opties – AWS Noord-Amerika alleen al heeft 31 Beschikbaarheidszones en 31 Edge-netwerklocaties – en sommige opties zijn veel betrouwbaarder dan andere.

Inderdaad, de US-EAST-1-regio van AWS, de oorzaak van de storing van deze week, was eerder achter grote verstoringen in 2020, 2021 en 2023, en het was lang bekend in bepaalde IT-kringen als de minst betrouwbare regio. Veel bedrijven hebben waarschijnlijk de situatie begrepen, maar namen een berekend risico vanwege de lage kosten en overvloedige aanbod van de regio. Maar gezien de omvang van de storing, is het onmogelijk om niet te overwegen hoeveel bedrijven volledig werden overvallen – en zeker voor de meer betrouwbare regio’s hadden gekozen als ze zich bewust waren van de compromissen. Ik heb persoonlijk IT-leiders ontmoet die hebben besloten om over te stappen naar andere AWS-regio’s na slechte ervaringen met US-EAST-1 in het verleden.

De les hier is om uw huiswerk te doen als het gaat om cloud-infrastructuur-opties, ongeacht welke cloud u gebruikt. Plaatsen om te beginnen zijn gratis tools zoals cloudprice, Cloudping, en de historische incidentenweergaven van hyperscaler-geleverde Cloud Service Health-tools.

Kies voor portable in plaats van cloud-native.

Wanneer u cloud-configuraties ontwerpt, is de eenvoudigste route om cloud-native te gaan. Maar hoewel het handig is om toepassingen te selecteren die speciaal zijn gebouwd door en voor uw cloud-provider, laten deze cloud-native opties u meer blootgesteld aan risico’s als uw cloud uitvalt.

Om die extra laag van cloud-afhankelijkheid te vermijden, kiest u voor onafhankelijke en/of open-source producten waar mogelijk. Een paar voorbeelden van vervangingen zijn de volgende:

Om zeker te zijn, het opbouwen van meer van uw cloud-stack van scratch betekent meer werk voor uw teams. Echter, uit mijn ervaring, zodra u de infrastructuur eenmaal heeft opgezet, is er weinig tot geen verschil tussen het toevoegen van workload aan een bestaande, zelfgemaakte infrastructuur of het gebruik van een cloud-native een. En de voordelen in termen van veerkracht – niet te vergeten de vermindering van cloud-lock-in – maken onafhankelijke opties zeer de moeite waard.

Ontwerp voor falen.

Aangezien cloud-falen zal gebeuren, zorg er dan voor dat u uw producten ontwerpt met cloud-falen in gedachten. Een voorbeeld om naar te kijken is Datadog: in een incident in 2023 verloor het bedrijf plotseling toegang tot meer dan de helft van zijn Kubernetes-knooppunten in productie en ontwierp volledig zijn rampenbenadering opnieuw. Veranderingen omvatten het verwijderen van architectonische flessenhalzen en het aanpakken van technische schulden, zodat gedeeltelijke storingen niet door het systeem zouden stromen, het verbeteren van gegevensinname en -opslag voor grotere gegevensbeschikbaarheid tijdens storingen, en het bouwen van systemen om automatisch op grote schaal te herstellen. Een goede plek om te beginnen in uw reis is om de aanbeveling van Datadog te volgen om “te beginnen met wat belangrijk is voor de eindgebruiker” en fail-safes te bouwen om te beschermen wat het meest telt.

Loop op ten minste twee clouds.

Natuurlijk is de beste manier om niet afhankelijk te zijn van cloud-falen, multicloud-redundantie. Het bereiken van echte multicloud-vloeibaarheid is een enorme onderneming voor veel bedrijven, omdat het extreem moeilijk is om infrastructuur van de ene cloud naar de andere te vertalen. Maar het opbouwen van infrastructuur op slechts twee clouds is een sterke – en vaak haalbare – plek om te beginnen. Criticale factor om dit te laten werken is het hebben van een team met een expert in elke cloud waarop u loopt.

Om zeker te zijn, kan niets bedrijven volledig beschermen tegen de impact van een massive storing zoals de een die we deze week zagen. Maar met de juiste due diligence, een cloud-portable benadering, ontwerp voor falen en het gebruik van “dual-cloud” als een stapsteen naar echte multicloud, kunnen bedrijven veel flexibeler zijn wanneer de volgende (en helaas onvermijdelijke) grote cloud-incident toeslaat.