Majority of web apps could just run on a single server
Many developers argue that most web applications could run cheaply on a single modest VPS, and that today’s default of Kubernetes clusters, microservices, and complex cloud setups is often unnecessary for typical traffic and uptime needs. Commenters highlight how overengineering is driven by resume-building, cloud vendor incentives, and misplaced 100%‑uptime expectations, while adding failure modes, cost, and operational burden. Others note that high‑scale or highly regulated systems do justify sophisticated infrastructure, but contend these are the minority compared with simpler apps that would benefit from leaner, monolithic deployments.
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.