I Didn't Need Kubernetes, and You Probably Don't Either

Original Article ↗ Hacker News Discussion ↗

Kubernetes is increasingly being questioned as the default choice for deploying applications, with many engineers arguing that its complexity, operational overhead, and cost are unjustified for small to medium workloads that could run on a single server, simple VMs, or managed platforms like Cloud Run or App Service. Others counter that Kubernetes shines once you truly need clustering, high availability, multi-team platforms, or multi-cloud portability, but warn that it requires real expertise and is often misapplied by startups chasing hype or résumé value. Across perspectives, a common theme is “use the right tool for the job,” with strong support for simpler PaaS or monolithic setups until scale, reliability, or compliance needs genuinely demand something as heavy as Kubernetes.

Right tool for the job / overengineering

  • Many argue most products could still run fine on 1–2 “beefy” servers or a simple VPS with a load balancer and scripts.
  • There’s a strong theme of “use the simplest thing that satisfies real requirements, not hypothetical scale or résumé goals.”
  • Several note a recurring industry pattern: hype cycles (Kubernetes, React, JS tooling) drive unnecessary complexity that later gets unwound.

Arguments for Kubernetes

  • Praised as a “cluster OS” / platform for running lots of heterogeneous workloads with HA, autoscaling, and standardized deployment APIs.
  • Especially valued where many teams share infrastructure, or where internal services going down blocks a lot of people.
  • Multi‑cloud and portability: some report 95–99% common manifests across EKS/GKE/OKE and on‑prem k8s.
  • Managed offerings (EKS/GKE, k3s/k3d) reduce control‑plane pain; some say a small k8s cluster is easier than managing many systemd units/VMs.

Arguments against Kubernetes

  • Steep learning curve, lots of moving parts, and brittle YAML; easy to end up with an unmaintainable “config spaghetti” if not designed by experts.
  • Overkill for tiny startups and simple web apps; operational overhead can consume engineering time better spent on product.
  • State and storage (PVCs, stateful services) add significant complexity; many prefer to keep state off‑cluster.
  • Some see it as resume‑driven or “cosplay infra,” creating unnecessary jobs and complexity.

PaaS, Cloud Run, and other alternatives

  • Strong support for PaaS: Cloud Run, Azure App Service, Heroku, ECS, Lambda, DigitalOcean App Platform, etc., as a sweet spot for most web apps.
  • Cloud Run is liked for scale‑to‑zero, simple container deploys, and “boring” ops, but called out for nuances: DB connection limits, eventing/back‑pressure, networking/VPC constraints.
  • Lightweight orchestration mentioned: Docker Compose, Docker Swarm, Nomad, k3s on a single bare‑metal box, simple bash/Ansible/Terraform.

Cost, scale, and startup needs

  • Disagreement on when zero‑downtime deploys and autoscaling are truly needed; some say they’re trivial and worth having early, others say they’re premature.
  • Control‑plane costs (~$70/month) are negligible for larger orgs but significant for tiny projects compared to one or two VMs.

Lock‑in, portability, and self‑hosting

  • Debate over “Kubernetes lock‑in” vs cloud‑vendor lock‑in; some see k8s as the portability layer, others note it’s just another dependency.
  • A few raise privacy concerns about public clouds and advocate self‑hosting on colo or cheap providers (Hetzner/OVH) with k3s or plain VMs.