Heb je als KMO echt Kubernetes nodig?

Je hoort het overal. Bedrijven die "naar de cloud migreren", "container-orchestration" nodig hebben, of "Kubernetes draaien". Het klinkt als de volgende logische stap zodra je applicaties niet meer louter op je eigen laptop draaien. En eerlijk: als je googelt naar hoe je je Docker-containers in productie zet, stuit je al snel op tutorials die Kubernetes als vanzelfsprekendheid presenteren.

Maar Kubernetes lost een specifiek soort probleem op. En dat probleem is niet "ik heb een applicatie die ergens moet draaien". Het is: "ik heb honderden services die onafhankelijk schalen, over meerdere servers verspreid moeten draaien, en continu moeten reconciliëren naar een gewenste staat." Dat is een probleem dat Netflix, Uber en Google hebben. De meeste KMO's niet.

In dit artikel: wat Kubernetes je wél geeft, wat je al met eenvoudigere tools oplost, en wanneer de overstap écht zin heeft.

Wat Kubernetes wél oplost

Laten we eerlijk beginnen: Kubernetes is geen speelgoed. Het lost echte problemen op die eenvoudigere tools niet of minder goed aanpakken. De belangrijkste:

• Hoge beschikbaarheid. Als één server uitvalt, herplant Kubernetes je applicatie automatisch op een andere. Geen menselijke tussenkomst nodig.
• Self-healing op node-niveau. Docker Compose herstart een gecrashte container, maar als de host zelf dood is, gebeurt er niets. Kubernetes detecteert een dode node en verplaatst de workloads.
• Zero-downtime rolling updates. Pas als een nieuwe versie écht gezond is, gecontroleerd via readiness-probes, krijgt die verkeer. Geen korte onderbreking bij elke deploy.
• Auto-scaling. Schaal horizontaal op basis van CPU, geheugen of custom metrics, zonder menselijke actie.
• Gedeclareerde reconciliatie. Iemand stopt per ongeluk een container? Kubernetes start hem opnieuw. Het systeem convergeert continu naar de gewenste staat.

Dat zijn allemaal dingen die je wil, als je de schaal hebt waar ze nodig zijn.

De vraag die je eigenlijk moet stellen

De vraag is niet "is Kubernetes goed?". Het is. De vraag is: "heb ik het probleem dat het oplost?"

Voor de overgrote meerderheid van KMO-applicaties is het eerlijke antwoord: nee. Een applicatie die op één of twee servers prima draait, heeft geen cluster van meerdere nodes nodig. Een team van vijf mensen dat samen één systeem onderhoudt, heeft geen orchestratie-platform nodig om tientallen onafhankelijk schalende services te beheren.

Dit sluit aan bij wat we eerder schreven over overengineering: Kubernetes is vaak een van de patronen die je software-budget ongemerkt opdrijft. Niet omdat het slechte technologie is, maar omdat het complexiteit toevoegt die het onderliggende probleem niet vraagt. Wat je opzet met docker compose en een degelijke reverse proxy kan elke ontwikkelaar in een uur uitleggen. Wat je opzet met een Kubernetes-cluster, vraagt een specialist om aan te passen, en die specialist is schaars en duur.

Wat je al zonder Kubernetes oplost

Veel van wat mensen naar Kubernetes drijft, kun je met eenvoudigere tools al adequaat aanpakken:

• Reverse proxy + automatische TLS: Traefik of Caddy in je Compose-stack.
• Zero-downtime deploys: Traefik met blue-green, of Docker Swarm.
• Multi-host en failover: Docker Swarm (ingebouwd in Docker, een fractie van de complexiteit).
• Management UI: Portainer.
• Monitoring en alerting: Prometheus + Grafana, draait ook prima in Compose.

Docker Swarm is daarbij een sterk ondergeschoven kindje. Het geeft je multi-host scheduling, rolling updates, service discovery en failover, zonder de operationele last van een volledig Kubernetes-cluster. Voor veel KMO's die "meer dan één server" willen, is dat de eerste logische stap, niet Kubernetes.

Ook je secrets hoef je niet naar Kubernetes te migreren. Tools als SOPS (SOPS-age of SOPS-GPG) zijn een prima, platformonafhankelijke oplossing die vaak zelfs robuuster zijn dan de standaard Kubernetes Secrets (die out-of-the-box enkel base64-gecodeerd zijn, niet versleuteld).

Wanneer de overstap wél zin heeft

Er zijn situaties waarin Kubernetes de juiste keuze is. De signalen dat je er bent:

• Je draait tientallen services die onafhankelijk van elkaar schalen en uitrollen.
• Eén server is geen optie meer, niet uit budgetoverwegingen, maar omdat je beschikbaarheidseisen vragen om echte failover over meerdere fysieke machines.
• Je hebt een team dat het kan onderhouden. Niet één enthousiaste developer, maar mensen die upgrades, security-patches en monitoring structureel aanpakken. Zeker nu steeds meer KMO's onder NIS2 vallen, is dat geen optionele luxe.
• Je wilt cloud-agnostic zijn en vendor lock-in vermijden, en je hebt de schaal om dat te rechtvaardigen.

Voldoe je aan twee of meer van die punten? Dan is managed Kubernetes, zoals Scaleway Kapsule, Azure AKS of Google GKE, een logische keuze. Let op: managed. Zelf een Kubernetes-cluster opzetten en onderhouden is voor vrijwel geen enkele KMO een goed idee.

Hoe we het bij Tandem aanpakken

Geen verrassing als je onze andere artikels gelezen hebt: we houden het bewust saai. Onze default-stack is een of twee applicatieservers op Scaleway, Postgres, Go als applicatietaal, Traefik als reverse proxy, en docker compose als orchestratie. Geen Kubernetes, tenzij er een concrete operationele reden is die het rechtvaardigt.

Dat is geen principiële afkeer van Kubernetes. Het is de erkenning dat voor 95% van de KMO-applicaties die we bouwen, de complexiteit van een cluster niet opweegt tegen het voordeel. Eén server die elke ontwikkelaar begrijpt, is goedkoper, stabieler en sneller aan te passen dan een ecosysteem dat een specialist vereist.

Wanneer een klant écht de schaal heeft waar Kubernetes zinvol wordt, en dat gebeurt, dan zetten we het neer. Maar we dwingen het niet af. Net zoals we eerst vragen of we iets wel moeten bouwen, vragen we eerst of we de complexiteit wel moeten introduceren.

Tot slot

De vuistregel is eenvoudig: als je je moet afvragen of je Kubernetes nodig hebt, heb je het waarschijnlijk niet nodig.

Start met wat het probleem vandaag vraagt. Een VPS met Docker Compose, een degelijke reverse proxy, goede backups, en monitoring dat je vertelt wanneer er iets mis is. Pas als je écht tegen de grenzen van die setup aanloopt, meerdere servers, schaal die elastisch moet meebewegen, teams die onafhankelijk moeten kunnen deployen, is het tijd om naar Kubernetes te kijken.

Tot die tijd is eenvoud geen compromis. Het is een strategisch voordeel.

Twijfel je of je huidige setup nog volstaat, of loop je tegen grenzen aan? We kijken er graag samen naar. Geen verkooppraatje, gewoon een eerlijke inschatting van wat je écht nodig hebt, en wat niet. Plan een kennismaking.