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 bescherming én beschikbaarheid bij storingen in een land of datacenter.
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 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 je 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 je gebruik kunt maken van regionale en wereldwijde spreiding. Hierdoor kun je 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 kun je ook één instantie als standaard instellen en gebruikers pas naar de andere versie sturen wanneer de eerste onbereikbaar is. Handig als je een wereldwijde dienst aanbiedt: de software blijft bereikbaar en werken wanneer het eerste datacenter een storing heeft.
Replicatie
Voor opslag, zoals bestanden en databases kun je een vergelijkbare maatregel treffen. Je 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, schakel je de software over naar de secundaire omgeving. Dit kan zodanig worden 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.
En dit waren niet de eerste de besten: 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 pluk je pas wanneer half internet plat ligt en jij 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.