Majority of web apps could just run on a single server

Original Article ↗ Hacker News Discussion ↗

Single-server capacity and real‑world anecdotes

  • Many commenters say a $4–$10/month VPS can handle thousands of requests per second or front-page HN traffic if the stack is simple and efficient.
  • Several report running multiple apps, search engines, small marketplaces, or 10M+ monthly pageviews on one modest machine with good engineering.
  • Classic “simple stacks” (e.g., LAMP, Go, PHP+Postgres, static sites with a small backend) are repeatedly cited as sufficient for most real-world loads.

Complexity, Kubernetes, and DevOps culture

  • Strong sentiment that Kubernetes and modern “cloud‑native” stacks are often unnecessary for small/medium apps and introduce brittle complexity.
  • Some note k8s is used simply because an engineer wanted to learn it or to follow perceived “best practices,” not because of actual requirements.
  • Others argue k8s provides a standardized API across clouds and is valuable for large orgs with many teams and services.

Uptime, redundancy, and reliability

  • Disagreement on how much uptime most apps truly need.
  • Some say occasional brief downtime is acceptable and far cheaper than complex HA setups.
  • Others stress that customers expect near‑100% uptime once they’re paying; redundancy (2–3 machines, failover, multi‑AZ) is then justified.
  • It’s noted that multi-node and multi-region architectures add many new failure modes and can hurt reliability if poorly understood.

Cost, resource use, and cloud overengineering

  • Multiple anecdotes of tiny actual traffic vs large, expensive cloud/Kubernetes setups, with engineers spending more time on Terraform/IaC than features.
  • Critique that cloud marketing and zero‑interest‑rate VC era encouraged overengineering and runaway OpEx.

Career incentives and resume‑driven design

  • Several argue that overcomplex architectures are driven by hiring and career incentives: flashy stacks, microservices, and k8s are rewarded; boring monoliths aren’t.
  • Pragmatic, single‑server solutions may be optimal for the business but less valuable for engineers’ resumes.

Middle ground and alternatives

  • Suggestions include: single VPS with automated deploys; containers without k8s (Docker/Swarm/Podman); simple active–standby failover; small k3s/k0s clusters.
  • General theme: start extremely simple, scale and add complexity only when real load, uptime requirements, or org size demand it.