Dear friend, you have built a Kubernetes

Original Article ↗ Hacker News Discussion ↗

Engineers debate whether Kubernetes is a necessary foundation for modern deployment or an over-engineered substitute for simpler tools like shell scripts, Docker Compose, or cloud autoscaling groups. Many argue that K8s’ complexity, operational overhead, and YAML sprawl are unjustified for small to mid‑scale systems, while others point to its standardized API, ecosystem, and portability as major long‑term advantages, especially at scale or in larger organizations. The thread repeatedly returns to trade‑offs: simplicity vs. standardization, cloud lock‑in vs. flexibility, and the impact of “résumé‑driven development” and hiring filters that increasingly expect Kubernetes experience.

Kubernetes complexity and when it’s justified

  • Many argue Kubernetes is “complexity abstracting over complexity” and unnecessary for small/medium systems that can run on 1–2 servers with shell scripts, systemd, or docker-compose.
  • Others say once you need many services, environments-on-demand, autoscaling, HA/DR, cert management, and standardized deployments, K8s becomes the least-bad option.
  • Several note that K8s is designed for Google-scale problems; 99% of orgs will never reach that scale, yet copy the tooling anyway.

Migration and operational pain

  • Multiple accounts of painful, multi‑month or multi‑year migrations (dozens to thousands of services) with outages caused by misconfigured limits, networking, or storage.
  • Some migrations eventually paid off via better autoscaling and resource utilization; others saw little to no cost savings versus well-tuned VMs/ASGs.
  • A recurring theme: orgs underestimate project design, testing, and observability work needed; “culture that wants optimistic timelines” is blamed.

Managed vs self‑hosted Kubernetes

  • Managed offerings (EKS/GKE/AKS) are seen as reasonable if you’re already in public cloud; self‑hosting K8s as a small org is often called a waste of money and staffing.
  • Where public cloud is off-limits (regulation, internal “cloud”), self‑managed K8s clusters are reported as fragile and hard to debug without strong infra teams.

Alternatives and “middle ground”

  • Alternatives praised: Docker Compose, Docker Swarm, Nomad, k3s/microk8s, ECS/Fargate, Kamal, NixOS scripts, CaaS platforms, and PaaS offerings (Heroku, Fly.io, Render, DO App Platform).
  • Many argue an opinionated, simpler orchestrator that sits between “bash + ssh” and full K8s is missing or underused.
  • Some say a well‑designed setup with ASGs, load balancers, Ansible/Terraform, and boring Unix tools is enough up to thousands of instances.

Shell scripts, “boring tech”, and bad practices

  • Strong support for simple deploys: “scp + script + HAProxy” works at surprising scale if you’re disciplined.
  • Critics counter that large shell-based systems tend to accumulate undocumented tweaks, brittle error handling, and ad‑hoc reimplementations of half of K8s.
  • Others reply that many “wins” attributed to K8s actually come from cleaning up bad practices (12‑factor, CI/CD, clearer configs), which could have been done without K8s.

Careers, hiring, and standardization

  • Several note K8s has become a de facto checkbox in job ads; lack of K8s experience can be an automatic rejection, regardless of broader sysadmin skills.
  • Supporters emphasize K8s as a common API and mental model across orgs and clouds, lowering onboarding cost—critics call this “resume-driven development” and vendor‑motivated standardization.