Intermediate

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. ...

Je metrics zeggen dat iets traag is. Je logs zeggen dat er errors waren. Prima. Beantwoord dan dit: welke request faalde nou eigenlijk, waar kwam die latency vandaan, en welke service in de keten vrat die timeout op? Metrics en logs halen daar allebei hun schouders bij op. Ik liep tegen die muur aan toen een checkout flow onder load begon te timeouten. Tien services in het pad, elk van ze groen op zijn eigen dashboard, en geen enkele manier om één gedoemde request te volgen van voordeur tot fout. Precies dat gat vult distributed tracing op. Het volgt één request terwijl die door je services beweegt en toont je precies wat er gebeurde en waar het vastliep. ...

Je hebt Prometheus voor metrics, dus je kunt al zien wat er gebeurt in je clusters. Metrics vertellen je dat de latency van een request om 14:32 piekte. Ze vertellen je niet dat de payment service een null pointer gooide omdat iemand een config-wijziging met een typefout uitrolde. Daarvoor heb je logs nodig. Het standaardantwoord was jarenlang Elasticsearch. Krachtig en flexibel, en het indexeert elke token in elke logregel. Die full-text index is geweldig totdat je naar de rekening kijkt. Je betaalt ervoor in CPU bij ingest, in RAM om de index warm te houden, en in opslag die sneller groeit dan je daadwerkelijke logvolume. Ik draaide ooit een ELK stack in een vorige baan en was meer tijd kwijt aan het tunen van JVM heap sizes dan aan het lezen van logs. ...

Vraag de meeste mensen hoe je thuis een “echte” hypervisor draait en je krijgt hetzelfde rijtje: VMware, Hyper-V, of op zijn minst Proxmox. Iets met een web UI, een clustering-tab, een marketingpagina vol enterprise features. Dat beeld zit er zo diep in dat virtuele machines draaien zonder zo’n product voelt als bochten afsnijden. We hebben stilletjes geaccepteerd dat serieuze virtualisatie met een leverancier komt. Draai het nu om. Wat in al die producten het echte werk doet, is een Linux kernel module die al meer dan tien jaar production-grade is. KVM met libvirt geeft je live migratie, memory ballooning, CPU pinning, GPU passthrough, SR-IOV, nested virtualization. De features waar de glanzende hypervisors mee adverteren zijn kernel features. De web UI is een schil eromheen. ...

Ik krijg steeds de vraag welke distro iemand op zijn dagelijkse machine moet draaien: Arch of NixOS. Meestal van mensen die al Linux draaien en een werkstation willen dat ze echt begrijpen, geen black box die zichzelf update op andermans schema. Ik heb beide gedraaid als mijn echte machine. Niet in VMs, niet als weekend-experiment. Als de laptop waar ik professioneel DevOps en platform engineering werk doe, en als de desktop waar ik al het andere doe. Laat ik mijn bias meteen op tafel leggen, want dit framework werkt alleen als ik daar eerlijk over ben: ik draai vandaag Arch op beide desktops, en NixOS op mijn servers. Dat verklapt waar ik uitkwam. Maar ik kwam daar om specifieke redenen, en die wil ik doorlopen in plaats van je een verdict in handen te drukken. ...