Platform Engineering

Zo wordt er in 2026 nog steeds veel infrastructuur gebouwd. Iemand opent een cloud console, klikt door een wizard, kiest wat defaults, en er verschijnt een resource. Het werkt. Het dashboard wordt groen. Iedereen gaat door met de volgende taak. Zo kan ik niet werken. Als ik op een knop klik en er verschijnt infrastructuur, voelt het alsof ik het geleend heb. Ik wil zien wat er gebeurt, ik wil de configuratie ergens opgeschreven hebben waar ik het terug kan lezen, en ik wil weten waarom iets bestaat in plaats van alleen dat het bestaat. De console geeft me een groen vinkje. Begrip geeft hij niet. ...

Elk platform team stelt uiteindelijk dezelfde vraag: moeten we een Internal Developer Platform bouwen? Het eerlijke antwoord is meestal ja. Het deel dat teams sloopt is de hoe. Ik heb platforms gezien die een klein fortuin kostten en daarna stilletjes verlaten werden omdat niemand ze wilde gebruiken. Ik heb ook een paar Helm charts en een Kyverno policy een heel team van manier zien veranderen waarop ze software shippen. Het gat tussen die twee uitkomsten heeft bijna niets met budget te maken, of met welke modieuze tool je koos. Het komt neer op de vraag of je begon met een echt probleem oplossen of met het platform bouwen dat jij dacht dat developers zouden moeten willen. ...

De eerste keer dat je een stateful workload op een self-hosted cluster draait, loop je tegen een muur. Geen cloud provider storage class om op te leunen. Alleen je nodes, hun disks, en een Postgres pod die weigert te schedulen omdat niets hem een PersistentVolume kan geven. Dus je gaat lezen, en binnen een uur heb je het teruggebracht tot twee namen die steeds terugkomen: Longhorn en Rook-Ceph. Ik heb beide in productie gedraaid. Dus laat me mijn bias meteen op tafel leggen: op kleine clusters kies ik standaard Longhorn, en waarom precies leg ik verderop uit. Houd dat in je achterhoofd terwijl je leest, want het kleurt hoe ik dingen weeg. Beide zijn CNCF projecten, beide geven je gerepliceerde block storage die overleeft als een node sterft, en beide zijn goede software. Ze zijn het alleen oneens over hoeveel complexiteit je zou moeten tekenen. ...

Lange tijd vernieuwde ik mijn certificaten zoals de meeste mensen dat doen: een agenda-reminder, een handmatige certbot-run en de stille hoop dat ik er op tijd aan zou denken. Dat werkte. Het werkte precies tot de ochtend waarop een service me om de oren sloeg met certfouten en ik geen idee had waarom, omdat de renewal-cron al weken stilletjes faalde. Dat is het stuk dat niemand je vertelt over handmatige TLS. De fout kondigt zichzelf niet aan. Het certificaat verloopt gewoon, meestal op het slechtst denkbare moment, en je komt erachter omdat een browser tegen iemand staat te schreeuwen. De kennis over vernieuwing eindigt in het hoofd van één persoon. Teams slaan HTTPS over op interne services omdat het handmatig optuigen vervelend genoeg is om uit te stellen. ...

De eerste keer dat een service niet meer resolvede in een van mijn clusters, zat ik een avond iptables chains te lezen. Honderden regels, gegenereerd door kube-proxy, van boven naar beneden geëvalueerd. Ik heb het echte probleem nooit gevonden. Ik herstartte een node en het was weg. Dat zat me meer dwars dan de outage zelf. Ik draaide iets dat ik niet kon lezen. Dat gevoel is waarom ik naar Cilium ben overgestapt. Het gebruikt eBPF om networking logica naar beneden te duwen, de Linux kernel in, en slaat iptables volledig over. Je krijgt betere performance, je kunt daadwerkelijk zien wat je verkeer doet, en network policies worden geen giswerk meer. ...