Als kind had ik een woord voor de dingen die me fascineerden: onkapotbaar. Onverwoestbaar was nooit helemaal het juiste woord, want onverwoestbaar betekent iets dat nooit kapot gaat. Onkapotbaar is beter. Het betekent iets dat blijft werken zelfs nadat het kapot is gegaan.
Ik weet nog precies wanneer die fascinatie begon. Een foto van een A-10 Thunderbolt II die terugkwam van een missie met een halve vleugel weg, de staart aan flarden en de romp vol gaten. Dat ding bracht zijn piloot alsnog thuis.
Dat is geen geluk. Dat is design.
Dingen die weigeren om te sterven
Ken je de verhalen van de Camel Trophy? Land Rover Defenders die door de Indonesische jungle werden gejaagd. Chassis verbogen, onderdelen eraf, alles onder de modder. En toch kwamen ze aan. Niet omdat er onderweg niks misging, want er ging de hele tijd iets mis. Ze kwamen aan omdat ze gebouwd waren om kapot te gaan en toch door te blijven rijden.
Vergelijk dat eens met een moderne auto. Eén sensor begeeft het en je staat op de vluchtstrook te wachten op een sleepwagen.
Ergens zijn we “robuust” en “complex” als hetzelfde gaan behandelen. Meer systemen, meer redundantie, meer failovers. Maar complexiteit is op zichzelf al een bron van falen. Elke extra component is een extra ding dat stuk kan, en een extra ding dat je moet begrijpen als het stukgaat.
Waarom ik dit doe voor werk
Ik bouw platforms voor mijn werk. Kubernetes clusters, GitOps pipelines, dat soort dingen. En ik betrap mezelf erop dat ik steeds dezelfde vraag stel: “wat gebeurt er als dit omvalt?”
Dat is een andere vraag dan “hoe voorkomen we dat dit 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. Servers crashen. Netwerken doen raar. Code heeft bugs. Dat is geen pessimisme, dat is gewoon het werk.
De meeste systemen die ik tegenkom zijn gebouwd voor het happy path. Alles werkt, requests komen binnen, responses gaan terug, de logs zijn groen. Prachtig. Dan gaat er iets scheef, wat altijd gebeurt, en dan blijkt dat niemand ooit besloten heeft wat er op dat moment moet gebeuren. Er is geen plan, alleen een stack trace en een Slack-kanaal dat vol begint te lopen.
Kubernetes en de illusie van zelfheling
Kubernetes wordt verkocht als “zelfhelend”. Pod gecrasht? Geen probleem, we starten een nieuwe. Node weggevallen? De workloads worden ergens anders herplaatst.
En ja, dat klopt allemaal. Tot op zekere hoogte.
Het addertje is dat een Kubernetes cluster zelf ook een systeem is dat kan falen. Wat gebeurt er als etcd corrupt raakt? Als je control plane omvalt? Als er een netwerk partitie ontstaat die je nodes in twee helften splitst die allebei denken dat zij de baas zijn?
Zelfheling binnen een cluster is mooi. Maar het cluster zelf is nog steeds een single point of failure. Dat is precies waar ik de laatste tijd mee aan het experimenteren ben: clusters die samen onkapotbaar zijn, waarbij het geheel blijft draaien ook als een heel cluster wegvalt.
Dat is een verhaal voor een andere post.
De vraag die ik mezelf stel
Elke keer als ik iets bouw, probeer ik mezelf af te vragen: is dit onkapotbaar?
Niet perfect. Niet onverwoestbaar. Kan dit ding zijn werk blijven doen terwijl de helft ervan in brand staat?
Meestal is het eerlijke antwoord nee. Dan wordt de volgende vraag: wat zou er moeten veranderen om het antwoord ja te maken?
Soms is de oplossing simpel. Soms is het antwoord “dit hele ontwerp moet anders”. En soms is het antwoord “dat is meer moeite dan dit specifieke probleem waard is”, wat ook prima is, zolang je die keuze bewust maakt in plaats van er om 3 uur ’s nachts achter te komen.
Niet alles hoeft onkapotbaar te zijn. Het punt is dat je nadenkt over wat er gebeurt als het kapot gaat, voordat het kapot gaat, terwijl je nog de luxe hebt om van gedachten te veranderen.
Dat is ook waarom ik fan ben van chaos engineering: bewust dingen kapotmaken om te ontdekken wat er dan gebeurt. Ik ontdek dat veel liever in een gecontroleerd experiment op een dinsdagmiddag dan om 3 uur ’s nachts met een trillende telefoon op het nachtkastje.