Je hebt waarschijnlijk geen Kubernetes nodig

Kubernetes is aantrekkelijk. Het klinkt volwassen, het is wat de grote namen gebruiken, en in een gesprek met een developer komt het al snel langs als “de juiste manier om het te doen”. Voor een vroege startup is het meestal de verkeerde manier.

Niet omdat Kubernetes slecht is. Omdat Kubernetes operationele problemen oplost die de meeste startups nog niet hebben. Het lost ze op tegen de prijs van complexiteit, kosten en afhankelijkheid van specifieke kennis, drie dingen waar een vroege startup juist mee wil oppassen.

Dit artikel staat stil bij waarom Kubernetes aantrekkelijk klinkt, wanneer het te vroeg is, waar de kosten daadwerkelijk zitten, en welke alternatieven in de meeste gevallen beter passen.

Waarom Kubernetes aantrekkelijk klinkt

Kubernetes wordt vaak verkocht met de juiste woorden: schaalbaar, gestandaardiseerd, hostingonafhankelijk, future-proof. Allemaal waar in de juiste context. Wat blijft hangen, is het idee dat je nu een fundering bouwt die later “gewoon meegroeit”.

Twee dingen worden daarbij meestal niet genoemd. Eén: die fundering komt met een vaste prijs in mensen en beheer, ook als je nog maar tien klanten hebt. Twee: voor de meeste vroege producten is het probleem niet “we kunnen niet schalen”. Het probleem is “we weten nog niet zeker waarop we zouden schalen”.

Een vroege startup heeft baat bij flexibiliteit van product en proces. Kubernetes biedt flexibiliteit op het niveau van infrastructuur, niet op het niveau waar de echte beslissingen voor jou liggen.

Wanneer het te vroeg is

Drie signalen waaraan ik herken dat Kubernetes (te) vroeg op tafel ligt:

De huidige hosting is “niet professioneel genoeg”. Het is geen technisch probleem. Het is een gevoel. Tien klanten op een VPS van €20 per maand is voor een vroege fase prima. Een herstart is niet beschamend.

Een ontwikkelaar wil het op zijn cv. Dat is begrijpelijk en mag bespreekbaar zijn. Het is alleen geen valide argument om de bedrijfsinfrastructuur op te bouwen. Een vroege startup heeft de kosten voor cv-bouwen niet in het budget.

De argumenten gaan over “later”. “Als we straks veel klanten hebben.” “Als we vier teams hebben die parallel werken.” “Als we naar drie regio’s uitrollen.” Dat zijn allemaal nuttige overwegingen, voor straks. Bouw niet voor klanten die je niet hebt, en niet voor teams die niet bestaan.

Het is meestal goedkoper om over een jaar te migreren naar Kubernetes vanaf een eenvoudige opstelling dan om vandaag al Kubernetes te draaien voor een product dat misschien een ander product wordt.

Kosten zitten vooral in mensen en beheer

De directe hostingkosten van een Kubernetes-cluster vallen vaak mee. Het zijn de tweede-orde-kosten die founders verrassen.

Mensen. Iemand moet weten hoe Kubernetes werkt. Niet alleen om het op te zetten, om het te onderhouden, te updaten, te debuggen en te repareren als er om 2 uur ‘s nachts iets stuk gaat. Die kennis is duur. Een freelancer die het opzet maar niet bereikbaar is voor onderhoud, levert geen duurzame oplossing.

Beheer. Updates, security patches, certificaatvernieuwingen, monitoring, alerts, logging, backup. Bij een eenvoudige opzet zijn dit een paar handelingen per maand. Bij Kubernetes worden het terugkerende werkzaamheden waar je rekening mee moet houden in je tempo en je hoofd.

Debugging. Als er iets niet werkt, is de fout in een Kubernetes-omgeving moeilijker te vinden dan in een eenvoudige opzet. Voor founders die de techniek niet beheersen, betekent dat afhankelijkheid van iemand met die specifieke kennis, meestal precies de persoon waarvan je weet dat je hem niet altijd te pakken krijgt.

Vendor lock-in van een ander type. Kubernetes claimt hostingonafhankelijkheid, maar in praktijk zit je aan een specifieke cloudprovider vast voor managed Kubernetes, of aan een specifieke beheerder voor zelf-geïnstalleerde clusters. Dat is een ander type afhankelijkheid dan een traditionele lock-in, maar het is er wel.

Alternatieven die voor de meeste vroege startups beter passen

Voor de meeste vroege producten dekken simpelere opties de echte behoeftes:

Een goede VPS bij een betrouwbare provider. Voor €20 tot €60 per maand draai je een Docker-omgeving die honderden gelijktijdige gebruikers aankan. Updates en onderhoud zijn beperkt. Bij een storing is de oorzaak vaak in een uur te vinden.

Managed hosting voor je framework. Heroku, Render, Fly.io, Railway en vergelijkbare diensten leveren een opzet waarin je vooral nadenkt over je product, niet over je infrastructuur. Iets duurder per maand, significant goedkoper in mensen.

Een platform-as-a-service van een grote cloudprovider. AWS Lightsail, Google Cloud Run, Azure App Service. Schaalt automatisch in redelijke grenzen en vraagt minimaal onderhoud. Voor de meeste vroege apps voldoende.

In alle drie de opties bouw je iets op dat over een jaar nog steeds werkt. Geen van drieën sluit Kubernetes uit als toekomstige stap.

Wanneer Kubernetes wél logisch wordt

Drie signalen waaraan ik herken dat Kubernetes inderdaad de juiste keuze begint te worden:

• Meerdere teams (drie of meer) werken parallel aan services die los moeten kunnen schalen, los moeten kunnen falen en los moeten kunnen worden vrijgegeven.
• De diversiteit aan workloads (data-pijplijnen, batch-jobs, web-frontends, langdurige processen) is groot genoeg dat een eenvoudige opzet niet meer scheidbaar is.
• Er is interne kennis (of betaalbaar in te huren expertise) om de operationele kant continu te ondersteunen, ook in stille weken zonder incidenten.

In al deze gevallen is Kubernetes geen marketingbeslissing. Het is een antwoord op aantoonbare operationele complexiteit. Voor het overgrote deel van de vroege startups bestaat die complexiteit nog niet.

Een simpele beslisregel

Voor founders die voor deze keuze staan, werkt deze regel meestal goed:

Begin met de eenvoudigste opzet die je product over zes maanden nog steeds kan draaien. Migreer pas als de eenvoudige opzet de bottleneck wordt, niet als hij ouderwets aanvoelt.

Een eenvoudige opzet vandaag betekent vrijwel altijd dat je over een jaar makkelijker een goed onderbouwde keuze kunt maken over wat er dan moet veranderen. Kubernetes nu kiezen betekent dat je nu jaar twee al betaalt voor een keuze die je in jaar één niet kon onderbouwen.

Voor de check vlak voordat een startup live gaat komen vergelijkbare keuzes terug: focus op wat klanten beschermt, niet op wat een infrastructuur professioneel laat klinken.

---

Sta je voor deze beslissing?

Stuur me kort de context of plan een gratis gesprek. Dan kijken we samen wat de meest verstandige volgende stap is voor je tijd, geld of focus vastlegt.

Plan een gratis gesprek → · Mail direct: hello@yourstartup.expert