Chaos in de cloud versterkt juist de weerbaarheid van applicaties

Cloud-omgevingen blinken uit in schaalbaarheid, maar dat brengt ook risico’s met zich mee. Immers is geen enkel bedrijf in staat om de wispelturigheid van miljoenen gebruikers volledig te simuleren met een beperkt QA-team. Chaos-driven infrastructure biedt hierin een oplossing.

In 2019 ontvingen we een gastbijdrage van Info Support over het gevaar van onvoorziene problemen in de IT-wereld. Daar kwam al het voorbeeld langs van Chaos Monkey, een tool die Netflix inzet om chaos te introduceren in de eigen diensten om de weerbaarheid ervan te verbeteren. Het is namelijk ondenkbaar voor een partij als Netflix om onbeschikbaar te zijn door een softwareprobleem. Vandaar de tool, die als een aap door een datacenter tekeer gaat en alle denkbare schade probeert aan te richten. Alleen door met die soort willekeurige aanvallen behendig te blijven, kan een applicatie echt weerbaar genoemd worden.

Weg met QA, omarm de chaos

Lee Atchison is een van de velen die pleit voor het voorbijgaan van QA bij het ontwikkelen van cloud-native applicaties. Hij prijst de dynamische aard van de cloud aan als krachtig middel om ter plekke problemen op te lossen op de achtergrond. Alleen dan is snelle innovatie mogelijk, meent hij.

Chaos-driven infrastructure gaat namelijk uit van een balans tussen chaos injections en geautomatiseerde probleemoplossingen. Het eindresultaat: een applicatie blijft in de lucht.

In 2020 verscheen een wetenschappelijk paper (PDF) vanuit de Universiteit van Potsdam waarin de onderzoekers pleitten voor Risk-driven Fault Injection (RDFI) om security van cloud-systemen te garanderen. Men ontwikkelde daarom CloudStrike, dat deze methodiek toepaste.

Principes

De principes achter ‘chaos engineering’ zijn door Principles of Chaos neergezet op de eigen website. Men gaat uit van 4 hoofdpunten. Allereerst is het belangrijk om een ‘steady state’ te definiëren, waarin een systeem zich naar behoren gedraagt. Vervolgens dient men een hypothese op te stellen dat deze steady state aanhoudt bij zowel de systemen waarin chaos wordt geïntroduceerd als een controlegroep waar dit niet gebeurt. Ten derde moet een engineer variabelen introduceren die de echte wereld nabootst: van crashende servers tot haperende harde schijven en afgebroken internetverbindingen. Ten slotte moet men zoeken naar een afwijking van de steady state tussen de chaos-gedreven testgroep en de controlegroep. Het doel is vanzelfsprekend: om een applicatie zoveel mogelijk in steady state te houden terwijl er chaotische variabelen erop afgevuurd worden.

De praktijk

Chaos als tool is dus niet nieuw, maar wordt wel steeds relevanter. Cloud-adoptie neemt toe, met ook nog eens veel dependencies en multi-cloud omgevingen die de complexiteit verhogen. Dit alles kan rekenen op een hoop uitdagingen. Denk aan gigantische gebruikersaantallen tegelijk, tijdelijke storingen bij delen van de dependency chain of bestaande kwetsbaarheden die cyber-aanvallers willen exploiteren.

Zo belanden we bij “chaos-based learning”, dat put uit zowel toepassingen als Chaos Monkey of CloudStrike als de praktische realiteit. Natuurlijk zal er veel programmeercode nodig zijn die developers moeten implementeren om grotere problemen aan te pakken. Ook vereist de chaos-insteek een andere gedachtegang dan voorheen, waarbij het niet zaak is om groen licht te krijgen vanuit QA maar actief te zoeken naar zwaktes.

Toch kan dit leiden tot kleinere “mean-time-to-resolution” voor problemen, omdat ze gepland kunnen worden. Daadwerkelijke problematiek schijnt de magische en ergelijke capaciteit te hebben om op de vervelendste momenten plaats te vinden. 3 uur ’s nachts op een zondag, bijvoorbeeld. Chaos-toetsing kan juist gepland worden wanneer support engineers beschikbaar zijn.

Vaccin

Crisismanagement zal van alle tijden blijven. Echter toont het voorbeeld van ex-Amazon development manager Kolton Andrus aan wat een incidentele uitval kan betekenen voor grote bedrijven. Hij sprak in een presentatie uit 2019 over een probleem waardoor Amazon.com drie kwartier uit de lucht was, met miljoenen dollars aan verloren omzet tot gevolg. Hij geeft aan dat het waarschijnlijk is dat grote incidenten juist plaatsvinden op momenten van grote drukte, dat een lucratieve dag kan transformeren tot een gemiste kans.

Omdat systemen nu continu veranderen en onoverzichtelijk groot zijn, meent Andrus dat de oude aanpak niet meer werkbaar is. Updates komen niet meer elk kwartaal, maar veelal wekelijks. “Er is altijd iets dat niet helemaal goed werkt,” stelt hij. Dit geldt niet alleen voor een individuele speler als Amazon, maar het gehele internet. De oplossing: chaos engineering, ofwel “breaking things on purpose”.

Door in te stellen op chaos, gedragen deze soort problemen zich als een virus, dat door een vaccin moet worden geweerd. Het is dezelfde metafoor als die bij Andrus’ presentatie. Immers heb je als engineer je systemen al getraind op chaotische acties met georganiseerde reacties. Andrus haalt eveneens brandoefeningen aan: niemand kan rekenen op een veilige en zorgvuldige evacuatie zonder erop voorbereid te zijn. In een wereld waarin online omgevingen in steeds meer sectoren essentieel worden, kunnen we niet werken met systemen die “hopelijk” in een crisissituatie snel weer operationeel gemaakt kunnen worden. Voor de geruststelling van gebruikers en werkbaarheid voor software-engineers, is chaos nodig als partner tegen ellende.