大多数网页应用其实只需在一台服务器上运行

单服务器容量与现实中的例子

• 许多评论者表示，一台每月 $4–$10 的 VPS 只要技术栈简单高效，就能处理每秒数千次请求，甚至承载 HN 首页流量。
• 也有人分享，凭借良好的工程实践，可以在一台普通机器上运行多个应用、搜索引擎、小型交易市场，或支撑每月 1000 万以上的页面浏览量。
• 经典的“简单技术栈”（例如 LAMP、Go、PHP+Postgres、带小型后端的静态站点）反复被提到，足以应对大多数现实负载。

复杂性、Kubernetes 与 DevOps 文化

• 很多人强烈认为，Kubernetes 和现代“云原生”技术栈对小型/中型应用往往是不必要的，并会引入脆弱的复杂性。
• 有人指出，使用 k8s 只是因为工程师想学，或想遵循自认为的“最佳实践”，而不是出于真实需求。
• 也有人认为，k8s 提供了跨云一致的标准化 API，对拥有大量团队和服务的大型组织很有价值。

可用性、冗余与可靠性

• 关于大多数应用究竟需要多高的可用性，存在分歧。
• 有人认为，偶尔的短暂停机是可以接受的，而且比复杂的高可用架构便宜得多。
• 也有人强调，一旦客户在付费，他们就会期待接近 100% 的可用性；这时冗余（2–3 台机器、故障切换、多可用区）就有其合理性。
• 有评论指出，多节点和多地域架构会增加许多新的故障模式，如果理解不透彻，反而会损害可靠性。

成本、资源使用与云端过度工程

• 多个例子都提到，实际流量很小，却使用了庞大而昂贵的云/Kubernetes 架构，工程师花在 Terraform/IaC 上的时间甚至比做功能还多。
• 还有批评认为，云厂商营销和零利率时代的风险投资环境助长了过度工程与失控的 OpEx。

职业激励与简历驱动的设计

• 一些人认为，过度复杂的架构是由招聘和职业激励推动的：炫目的技术栈、微服务和 k8s 会得到奖励，而平淡的单体应用不会。
• 对业务最优的务实单服务器方案，可能对工程师简历的价值却更低。

折中方案与替代选择

• 建议包括：带自动化部署的单一 VPS；不使用 k8s 的容器方案（Docker/Swarm/Podman）；简单的主备故障切换；小型 k3s/k0s 集群。
• 总体主题是：从极其简单的方案开始，只有在真实负载、可用性要求或组织规模确实需要时，才逐步扩展并增加复杂性。