Als kind noemde ik de dingen die me fascineerden onkapotbaar. Onverwoestbaar klopte nooit, want onverwoestbaar is iets dat nooit kapotgaat. Onkapotbaar is iets dat blijft werken nadat het kapot is.
Ik weet nog precies waar het begon. Een foto van een A-10 Thunderbolt II, terug van een missie met een halve vleugel weg, de staart aan flarden en de romp vol gaten. Dat ding bracht zijn piloot gewoon thuis.
Geluk had daar niks mee te maken. Iemand heeft jaren voor die missie aan een tekentafel besloten dat dat vliegtuig er zo uit mocht zien en toch thuis moest komen.
Dingen die weigeren dood te gaan
Ken je de verhalen van de Camel Trophy? Land Rover Defenders die door de Indonesische jungle werden gejaagd, chassis verbogen, onderdelen eraf, alles onder een laag modder. En ze kwamen aan. Onderweg ging de hele tijd iets mis. Ze kwamen aan omdat ze gebouwd waren om kapot te gaan en dan door te rijden.
Zet daar een moderne auto naast. Eén sensor begeeft het en je staat op de vluchtstrook op de sleepwagen te wachten.
Ergens zijn “robuust” en “complex” hetzelfde woord geworden. Meer redundantie, meer failover, systemen bovenop systemen. Maar complexiteit faalt ook helemaal in z’n eentje. Elk extra onderdeel is er een dat stuk kan, en een dat je moet snappen als het stukgaat.
Waarom ik dit voor mijn werk doe
Ik bouw platforms, dat is m’n werk. Kubernetes-clusters, GitOps-pipelines, dat soort dingen. En elke keer betrap ik mezelf op dezelfde vraag. Wat gebeurt er als dit omvalt?
Dat is een andere vraag dan hoe we voorkomen dat het omvalt. Voorkomen is belangrijk, maar dat is een apart probleem. Ik wil weten wat er gebeurt als het ding toch omvalt, want dat gaat het doen. Servers crashen en code heeft bugs. Netwerken doen dingen waar niemand op gerekend had. Noem het pessimisme als je wilt. Ik noem het gewoon werk.
De meeste systemen die ik tegenkom zijn gebouwd voor het happy path. Requests komen binnen, responses gaan terug, de logs zijn groen. Dan gaat er iets scheef, en dan blijkt dat niemand ooit heeft besloten wat er op dat moment moet gebeuren. Geen plan. Wel een stacktrace en een Slack-kanaal dat begint vol te lopen.
Kubernetes en de illusie van zelfheling
Kubernetes wordt verkocht als zelfhelend. Pod gecrasht? Er start een nieuwe. Node weg? De workloads landen ergens anders.
Klopt allemaal. Tot op zekere hoogte.
Het addertje is dat het cluster zelf ook een systeem is dat kan falen. etcd kan corrupt raken. Het control plane kan omvallen. Een netwerkpartitie kan je nodes in twee helften splitsen die allebei denken dat zij de baas zijn, en aan de zelfheling hierboven heb je dan niks.
Heling binnen een cluster is mooi, en het cluster zelf blijft een single point of failure. Daar experimenteer ik de laatste tijd mee, clusters die samen onkapotbaar zijn, waarbij het geheel blijft draaien als een heel cluster wegvalt.
Dat is nog een experiment, dus dat krijgt een eigen post als het standhoudt.
De test die ik draai voor ik iets bouw
Voor ik iets bouw, leg ik het naast dat woord van vroeger. Perfect is de verkeerde lat, onverwoestbaar ook. Blijft dit ding z’n werk doen terwijl de helft ervan in brand staat?
Meestal is het eerlijke antwoord nee. Dan wordt de volgende vraag wat er moet veranderen om er ja van te maken.
Soms is dat klein. Soms is het antwoord “dit hele ontwerp moet anders”. En soms is het “meer moeite dan dit probleem waard is”, en dat is ook prima, zolang ik die keuze bewust maak in plaats van er tijdens een storing achter te komen.
Niet alles hoeft onkapotbaar te zijn. Wat ik wil is dat iemand heeft nagedacht over wat er gebeurt als het kapotgaat, vóór het kapotgaat, toen van gedachten veranderen nog goedkoop was.
Daarom ben ik zo’n fan van chaos engineering. Bewust iets kapotmaken, op een dag die ik zelf kies, en kijken wat er gebeurt. Dat leer ik liever van een experiment dat ik zelf heb ingepland dan van een storing die ik niet zag aankomen. En die foto van de A-10 zit nog steeds in m’n hoofd, elke keer als ik er een draai.