HomeStrategie ❱ AWS storing brengt halve wereld offline

Twee weken geleden schreef ik een stuk over de beveiliging en beschikbaarheid van cloud databases. In de conclusie merkte ik op dat cloud infrastructuur prachtige mogelijkheden biedt om applicatie en database te configureren voor optimale bescherming én beschikbaarheid bij regionale/lokale/technische storingen in een land, datacenter, rack, stroomvoorziening of harde schijf.

En hoe toevallig: een dag later ligt half internet eruit vanwege een storing bij Amazon Web Services. Staat "de cloud" er even mooi op! En ik met mijn mooie verhaal ook.

Decentralisatie?

Wat ik interessant vind om te lezen op bijvoorbeeld Twitter, is de roep om "decentralisatie". Critici van de cloud zeggen het graag: cloud is niets anders dan "andermans server", het is ongezond dat zoveel websites in hetzelfde datacenter draaien, et cetera. De impact van deze storing is enorm en zet mensen terecht aan het denken. Het klinkt misschien gek, maar ik zie deze storing en de impact ervan juist als een pleidooi vóór de cloud.

Bouw voor rampscenario's!

Cloud applicaties -en eigenlijk alle maatwerk software- moet u laten bouwen voor rampscenario's. De software moet expliciet uitgaan van storingen. Bouwend voor rampscenario's dwingt een ontwikkelaar zich om gebruik te maken van de instrumenten die de cloud biedt om software flexibel en storings-beproefd te maken.

En die zijn er volop: cloud infrastructuur bevat instrumenten waarmee software uitermate goed weerbaar kan worden gemaakt tegen technische, lokale, landelijke en zelfs regionale storingen. Dat is helemaal niet ingewikkeld: vaak zijn het opties die alleen maar moeten worden ingeschakeld. En betaald, natuurlijk.

Twee van zulke instrumenten die in dit geval goed van pas waren gekomen, zijn load balancing en replicatie.

Load balancing

Eén van de grote voordelen van cloud infrastructuur is dat u gebruik kunt maken van regionale en wereldwijde spreiding. Hierdoor kun u bijvoorbeeld twee 'instanties' van uw software actief maken op twee werelddelen, en door een mechanisme dat load balancing heet, verkeer tussen deze twee instanties verdelen.

Daarbij kunt u ook één instantie als standaard instellen en gebruikers pas naar de andere versie sturen wanneer de eerste onbereikbaar is. Handig als u een wereldwijde dienst aanbiedt: de software blijft bereikbaar en werken wanneer het eerste datacenter een storing heeft.

Replicatie

Voor opslag, zoals bestanden en databases kunt u een vergelijkbare maatregel treffen. U stelt één lokatie van bestanden als primair in en laat alle wijzigingen in die bestanden op de achtergrond repliceren naar een secundaire locatie - bijvoorbeeld, aan de andere kant van de wereld.

Wanneer de primaire bestanden onbereikbaar raken, schakelt u de software over naar de secundaire omgeving. Dit kan zodanig worde ontworpen dat het automatisch gebeurt, na een bepaalde storingsperiode of een x aantal mislukte verbindingen.

De AWS storing

De storing bij AWS vond plaats in de S3 service (opslag) in één regio, US-East-1. De software en websites die hierdoor plat gingen, maakten waarschijnlijk geen gebruik van load balancing of replicatie. Het waren niet de eerste de beste: het betrof veel wereldwijde cloud services, waaronder Docker, Medium en Yahoo webmail.

Zijn deze websites dan dus slecht in elkaar gezet? Natuurlijk niet. Waarschijnlijk is er in veel gevallen een weloverwogen keus gemaakt: load balancing. replicatie en andere voorzorgsmaatregelen kosten geld.

De vruchten hiervan, die plukt u pas wanneer half internet plat ligt en u niet. OK, en een béétje tussentijds, vanwege een betere nachtrust.

Want de kans op zo'n storing... die is nog steeds best klein. Maar de impact is enorm, dat hebben we nu wel kunnen zien.

Auteur(s): Jorrit Venema

Plan nu een strategiegesprek 

of download de handleiding "Een succesvol software project"

VAART software Kanaalweg 18G 3526KL Utrecht KvK 30187211

Home 

Contact 

Privacyverklaring