BYTEHERDEREen platform verdient zijn bestaan door werk weg te nemen bij de teams die het gebruiken. Voegt het een laag toe zonder er een weg te halen, dan is het een kostenpost met een logo.
Wat hieronder valt
Clusterarchitectuur en -omvang, netwerk en ingress, identity en RBAC, secrets, opslag, policy, GitOps-levering, telemetrie, upgrades en disaster recovery. Eén cluster of een vloot. Op managed Kubernetes, op bare metal, of allebei tegelijk.
Het werk begint meestal als een inventarisatie van wat er staat: wat draait waar, wie mag het wijzigen, wat breekt er bij een upgrade, en welke onderdelen heeft al twee jaar niemand aangeraakt omdat niemand nog weet wat ze doen.
De meeste teams met Kubernetes hebben minder clusters en een gepubliceerde interface nodig, geen platformteam.
Een platformteam zonder gepubliceerde interface wordt een ticketwachtrij. Elk verzoek is maatwerk, elk antwoord zit in iemands hoofd, en de echte API van het platform blijkt een chatkanaal te zijn. Schrijf op wat het platform belooft, dus hoe een dienst aan een namespace, een ingress, een secret, een dashboard en een rollback komt, en het grootste deel van die wachtrij wordt selfservice. Is Kubernetes niet wat die beloftes goedkoop houdt, dan zeggen we dat voordat je nog een cluster koopt.
Wanneer dit het juiste werk is
- Meerdere teams bouwen ieder op hun eigen manier ingress, secrets, logging en CI-lijm opnieuw.
- Clusters blijven op een oude versie staan omdat het upgraderisico nooit is gemeten.
- RBAC is óf ruim genoeg om een auditor zorgen te baren, óf strak genoeg dat mensen eromheen werken.
- Infrastructuurkosten zijn één factuurregel, zonder toewijzing aan een workload of een eigenaar.
- Multi-region, multi-cloud of een gereguleerde omgeving staat op de roadmap.
- Een nieuwe dienst live krijgen kost weken en niemand kan aanwijzen welke stap de trage is.
Wat er verandert
Clusterstaat is gedeclareerd en reproduceerbaar, dus opnieuw opbouwen is een procedure en geen opgraving. Upgrades lopen over een pad dat getest is in plaats van gehoopt. Workload-grenzen, quota en policy zijn expliciet. Telemetrie beantwoordt vragen over eigenaarschap, niet alleen over resources.
De overdracht bestaat uit runbooks en dashboards die je eigen engineers kunnen lezen zonder ons erbij. Dát is het punt waarop het werk af is.
Hoe we eraan werken
Eerst het draaiende systeem bekijken, voordat we iets voorstellen. Eigenaarschap, dataflow en trust boundaries modelleren. Weghalen wat het platform niet hoeft te dragen. Dan bouwen, toetsen tegen echt falen, en de redenering opschrijven zodat de volgende engineer het argument erft en niet alleen de YAML.
Gereedschap waar we vaak naar grijpen
Per probleem gekozen, niet per mode. Zo ziet de kast eruit.