Begin nu met voorbereiden op de volgende cloud-storing

Grote cloud-incidenten zoals die van deze week van 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 deze week van AWS 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-computing realiteit. Wat kan uw bedrijf dus doen om de klap te verzachten? Hieronder zal ik vier stappen bieden die uw team onmiddellijk kan nemen.

Breng uw scepsis mee – en doe uw huiswerk.

Vaak lopen teams het risico 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 heeft 31 Availability Zones en 31 Edge Network Locations – en sommige opties zijn veel betrouwbaarder dan de anderen.

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

De les hier is om uw huiswerk te doen bij 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 zijn gebouwd door en voor uw cloud-provider, laten deze cloud-native opties u meer blootstellen als uw cloud uitvalt.

Om die extra laag van cloud-afhankelijkheid te vermijden, kies 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 up en running heeft, is er weinig tot geen verschil tussen het toevoegen van workload aan een gevestigde zelfgemaakte infrastructuur of het opereren op 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.

Gezien dat 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 architecturale flessenhalzen en het aanpakken van technische schulden zodat gedeeltelijke storingen niet zouden doorsijpelen in het systeem, het verbeteren van gegevensinname en -opslag voor grotere gegevensbeschikbaarheid tijdens storingen, en het bouwen van systemen om automatisch te herstellen op grote schaal. Een goede plek om te beginnen in uw reis is om Datadog’s aanbeveling 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 gebonden te zijn aan 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. Belangrijk om dit te laten werken is om een team te hebben met een expert in elke cloud waarop u loopt.

Om zeker te zijn, kan niets bedrijven volledig beschermen tegen de impact van een massale storing zoals die van deze week. 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 plaatsvindt.