Jarenlang was het kiezen van een technologie een ingenieursbeslissing: kosten, risico’s, teamvaardigheden en echte behoeften. Maar in delen van de softwaresector is Kubernetes geëvolueerd van een krachtige tool naar een statussymbool. In sommige technische interviews, voorstelprocedures en zelfs koffiepraatjes lijkt de vraag verplicht: “ gebruiken jullie Kubernetes?”. En te vaak wordt het antwoord geïnterpreteerd als een teken van volwassenheid of juist van achterhaaldheid.
Dit is de onderliggende kritiek die opnieuw de ronde doet in technische gemeenschappen, na een uitgebreide reflectie van een cloudprofessional op LinkedIn. Zijn stelling is prikkelend, maar herkenbaar voor iedereen die in moderne infrastructuren werkt: Kubernetes is buitengewoon wanneer het het juiste probleem oplost; voor anderen kan het een onnodige complexiteit worden die je betaalt.
Van engineering tot “cargo cult”: de vorm kopiëren zonder de kosten te begrijpen
De tekst neemt een klassiek idee uit de technologische wereld op: het “cargo cult”, een metafoor over het kopiëren van externe rituelen in de hoop dezelfde resultaten te behalen. In de cloud betekent dat het zien dat hyperscaler-bedrijven of wereldwijde platforms Kubernetes gebruiken en aannemen dat het repliceren van die architectuur automatisch betrouwbaarheid, snelheid of succes oplevert.
In de praktijk ontdekken veel organisaties vroeg of laat dat Kubernetes niet slechts “containers orkestreert”: het introduceert een compleet besturingssysteem. Ingress-controllers, certificaatbeheer, geautomatiseerde DNS, netwerkbeleid, observability, geheime beheer, frequente upgrades, compatibiliteiten tussen versies… en vooral gespecialiseerde kennis om al die onderdelen te draaien zonder dat elke storing een lange nacht wordt.
De auteur uit zijn ironie: de industrie heeft “schaalbaarheid” verward met “geloofwaardigheid”, alsof iedereen op het punt staat voor een probleem met miljoenen gebruikers. En dat is niet zo. De meeste bedrijven willen iets veel eenvoudiger: snel uitrollen, zonder menselijke fouten, met redelijke hoge beschikbaarheid en zonder de helft van het team aan de platform te besteden.
De terugkeer van de sysadmin: fundamenten voorop, niet rituelen
Een ander deel van de boodschap raakt aan een cultureel debat: het gevoel dat het klassieke profiel van de systeembeheerder — diegene die processen, geheugen, netwerk, permissies, diagnoses begrijpt — ondergewaardeerd is ten opzichte van moderne rollen vol afkortingen en tools die beloven alles te abstraheren.
De kritiek is niet tegen de cloud of DevOps als discipline, maar tegen het “toneel van complexiteit”: het aannemen van lagen en lagen als teken van verfijning. Het korte geheugen is simpel: wanneer iets ‘s nachts kapotgaat, is het niet het slogan, maar kennis van de fundamenten en het vermogen om te debuggen dat het systeem redt.
De praktische case: urenlange deployments reduceren tot minuten zonder Kubernetes
Het meest concrete stuk — en dat waar productteams vooral in geïnteresseerd zijn — is wanneer de auteur beschrijft hoe zijn team de tijd van ongeveer 2,5 uur voor handmatige deployments know hoe ver bekniptte automatisering, zonder Kubernetes te gebruiken.
De beschreven aanpak steunt op een veelgebruikte strategie binnen AWS: ECS met Fargate (container “serverless” in die zin dat er geen knooppunten beheerd worden), gecombineerd met scripting (bijvoorbeeld in Python met boto3) om resources idempotent te creëren en te configureren. De samenvatting klinkt eenvoudig, maar zeer effectief:
- een container image bouwen en publiceren,
- de service uitrollen of bijwerken,
- load balancer, certificaten en DNS programmatisch configureren,
- en de platform de rolling deployment en health checks laten afhandelen.
Het punt is niet om Fargate als universele oplossing te promoten, maar om te laten zien dat voor bepaalde teamgroottes en workloads de winst ligt in het verminderen van operationele oppervlakte, niet in het vergroten ervan.
Wanneer is Kubernetes zinvol en wanneer niet?
De reflectie is, ondanks de scherpe toon, geen “anti-Kubernetes”. Integendeel, het presenteert een redelijk criterium dat veel adviesbureaus herhalen… maar niet altijd toepassen:
Kubernetes is meestal zinvol wanneer:
- er tientallen of honderden services met complexe behoeften zijn,
- er een dedicated platformteam bestaat,
- de portabiliteit (multi-cloud of multi-hybride) een vereiste is,
- gevorderde patronen nodig zijn (operatoren, complexe stateful sets, massale jobs, servicemesh, etc.).
Alternatieven zoals ECS/Fargate (of andere managed platformen) passen beter wanneer:
- het aantal services beperkt is,
- het team klein is of focus op product wil houden,
- de snelheid van uitrol belangrijker is dan finetuning,
- het onderhoud van de orkestratielaag minimaal moet blijven.
Uiteindelijk is het een oproep om jezelf weer de juiste vraag te stellen: “Wat is het werkelijke probleem dat we willen oplossen?” Als het antwoord “snel uitrollen zonder gedoe” is, dan hoeft de oplossing niet de complexiteit te hebben van een platform dat op wereldschaal opereert.
De valkuil van de “industry norm”
Kubernetes is de standaard geworden, ja. Maar “standaard” betekent niet “verplicht”. Die verwarring kost je: overdimensioneerde architectuur, verbrande teams door operationele druk, budget dat naar platform gaat in plaats van product, en paradoxaal genoeg tragere leveringen.
Het debat stopt niet snel, omdat het technologie mengt met professioneel identiteit. Maar de discussie heeft waarde: in een tijd waarin veel bedrijven efficiëntie willen, frictie willen verminderen en time-to-market willen verbeteren, kan het vragen “waarom eigenlijk” de meest slimme beslissing zijn.
Veelgestelde vragen
Is Kubernetes noodzakelijk voor een middelgroot bedrijf?
Niet per se. Het kan een goede keuze zijn bij schaal- en complexiteitseisen en een team dat het kan beheren, maar veel middelgrote bedrijven halen robuuste deployments met managed platforms en automatisering.
Wat betekent “cargo cult” toegepast op Kubernetes?
Het beschrijft het overnemen van tools of architecturen door imitatie (omdat grote bedrijven het gebruiken), zonder te beoordelen of de operationele kosten en complexiteit passen bij het werkelijke probleem en de teamgrootte.
Wat zijn alternatieven voor Kubernetes voor productie-omgevingen?
Dat hangt af van de provider en situatie: AWS ECS/Fargate, managed containerdiensten, PaaS voor continue deployment, of eenvoudigere aanpakken met automatisering en best practices op VMs waar mogelijk.
Hoe weet ik of mijn bedrijf “Kubernetes nodig heeft” of dat we het alleen gebruiken omdat het in de markt lijkt te moeten?
Een praktische indicatie: als het beheer van het platform een dedicated team vereist (of je focus op product haalt), als upgrades en debugging te veel tijd kosten, en je echte behoeften geen geavanceerde orkestratie vereisen, betaal je waarschijnlijk onnodige complexiteit.