Als kind had ik een woord voor dingen die me fascineerden: onkapotbaar. Niet “onverwoestbaar” — dat impliceert dat iets nooit kapot gaat. Onkapotbaar is anders. Het betekent dat iets zelfs kapot nog werkt.
Ik weet nog precies wanneer die fascinatie begon. Een foto van een A-10 Thunderbolt II, teruggekeerd van een missie. Halve vleugel weg. Staart aan flarden. Romp vol gaten. En toch had dat ding zijn piloot thuisgebracht.
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 Indonesische jungle werden gejaagd. Chassis verbogen, onderdelen afgebroken, alles onder de modder. En toch kwamen ze aan. Niet omdat er onderweg niks misging — er ging constant iets mis. Ze kwamen aan omdat ze gebouwd waren om kapot te gaan en toch door te rijden.
Vergelijk dat eens met moderne auto’s. Eén sensor die uitvalt en je staat langs de weg te wachten op de ANWB.
Ergens zijn we “robuust” gaan verwarren met “complex”. Meer systemen, meer redundantie, meer failovers. Maar complexiteit is zelf een bron van falen. Elke extra component is een extra ding dat stuk kan.
Waarom ik dit doe voor werk
Ik bouw platforms. Kubernetes clusters, GitOps pipelines, dat soort dingen. En ik merk dat ik constant dezelfde vraag stel: “Wat gebeurt er als dit omvalt?”
Niet “hoe voorkomen we dat dit omvalt?” — dat is een andere vraag. Een belangrijke, maar een andere. Ik wil weten wat er gebeurt als het toch omvalt. Want het gaat omvallen. Servers crashen. Netwerken doen raar. Code heeft bugs. Dat is geen pessimisme, dat is gewoon hoe het werkt.
De meeste systemen die ik tegenkom zijn gebouwd voor het happy path. Alles werkt, requests komen binnen, responses gaan terug, logs zijn groen. Mooi. Maar zodra er iets scheef gaat — en dat gaat het — blijkt er niemand nagedacht te hebben over wat er dan moet gebeuren.
Kubernetes en de illusie van zelfheling
Kubernetes wordt vaak verkocht als “zelfhelend”. Pod crashed? Geen probleem, we starten een nieuwe. Node valt weg? Workloads worden automatisch verplaatst.
En ja, dat klopt. Tot op zekere hoogte.
Maar een Kubernetes cluster is zelf ook gewoon een systeem dat kan falen. Wat als etcd corrupt raakt? Wat als je control plane omvalt? Wat als er een netwerk partitie ontstaat tussen je nodes?
Zelfheling binnen een cluster is mooi. Maar het cluster zelf is nog steeds een single point of failure. En dat is precies waar ik mee aan het experimenteren ben — clusters die samen onkapotbaar zijn, ook als individuele clusters omvallen.
Maar 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. Maar kan dit ding zijn werk blijven doen als de helft ervan in brand staat?
Meestal is het antwoord nee. En dan is de volgende vraag: wat zou er moeten veranderen om het antwoord ja te maken?
Soms is het antwoord simpel. Soms is het antwoord “dit hele ontwerp moet anders”. En soms is het antwoord “dat is te veel moeite voor dit specifieke probleem” — ook prima, zolang je die keuze bewust maakt.
Het punt is niet dat alles onkapotbaar moet zijn. Het punt is dat je nadenkt over wat er gebeurt als het kapot gaat. Voordat het kapot gaat.
Dit is ook waarom ik fan ben van chaos engineering — bewust dingen kapotmaken om te ontdekken wat er dan gebeurt. Liever in een gecontroleerde setting dan om 3 uur ’s nachts.