公司在进行了 11 周的 Kubernetes 迁移后忘记了自己存在的原因（2020）
一篇讽刺公司在进行 11 周 Kubernetes 迁移后“忘记了自己为何存在”的文章，引发工程师们对现实中过度工程化和追逐新技术的反思。许多人描述了持续数年的平台迁移，产品路线图因此停滞；背后驱动因素包括简历驱动开发、错位的激励，以及对新工具的迷恋而非业务需求。评论者主张更紧的范围控制、渐进式变更，并把注意力放回真实产品，而不是为了基础设施本身而搞复杂化。
文章的讽刺与语气
- 许多读者很快就认出这是一篇仿讽作品，并将其与硅谷风格的讽刺相比较。
- 灵媒 / 材料设计的笑点，以及“忘记产品目的”的包袱效果很好。
- 有几位读者指出，同一博客上的其他帖子也常常不舒服地贴近现实，使讽刺与真实之间的界线变得模糊。
真实世界中的 Kubernetes 迁移经历
- 多位评论者表示，11 周完成迁移实际上已经是巨大成功；他们所在的公司进行 K8s / 平台迁移已经 1–3 年以上，仍未完成。
- 也有人认为，如果你已经在运行 Docker 且系统简单，11 周“应该”足够。
- 这种“应该”被描述复杂现实的人所质疑：老旧大型机、过时的 Java、与硬件绑定的许可证锁、未知的外部依赖、严格的公司政策，以及官僚流程。
- 还有人报告了部分迁移的情况（例如 2 年后只完成 30%），并且为了平台工作，产品路线图被暂停。
技术栈崇拜 vs 商业价值
- 核心解读是：团队沉迷于 Kubernetes / 新技术栈，却忘了产品究竟是用来做什么的。
- 有几位评论者形容一些公司在“模仿”大厂，尽管它们主要只是销售或业务组织，技术需求其实很有限。
- 迁移往往缺乏明确的业务问题；有时现有方案（例如 ECS）完全没问题。
云与 Kubernetes 策略之争
- 一派观点认为：如果你不是基础设施业务，就用现成的云服务，避免自管 K8s；这只会增加成本、复杂度和人头。
- 另一派则认为：托管 Kubernetes（如 EKS 等）通常是合理的，并且可以减少锁定、支持可扩展的地理分布式架构。
- 争论还涉及云成本的意外增加（尤其是出网流量、NAT 以及各种隐藏收费），以及对多云 / 可移植性担忧是否合理。
范围蔓延与迁移实践
- 一个常被提到的失败模式是：利用 K8s 迁移同时升级库、切换数据库并重构系统。
- 从业者的建议：
- 先从小而低风险的服务开始学习。
- 一次只做一个重大变更。
- 从最简单可行的方案开始；以后再添加 GitOps 自动化之类的工具。
行业激励与行为
- 晋升和认可往往偏向于大型、亮眼的项目，而不是默默维护可靠系统。
- 简历驱动开发和对概念验证的偏爱，推动人们不断重写（K8s、GraphQL、React、AI），而不是做渐进式改进。
- 有些人认为 devops / 平台领域的频繁变动是一种职业安全保障；也有人把责任归咎于管理层，因为他们把激励与“变化”而不是“价值”对齐。