本文永久链接 – https://tonybai.com/2025/mm/dd/the-voice-of-k8s-experts-report-2025

大家好，我是Tony Bai。

过去的一年，企业 IT 基础架构领域经历了一场剧烈的地震。震中，正是由博通（Broadcom）对 VMware 的收购所引发。这场地震带来的，不仅仅是技术栈的更迭，更是一场关于成本、信任与未来路线的“大迁徙”。

最近，我读到一份来自 Portworx 的《2025 年 Kubernetes 专家之声报告》，它用翔实的数据，为这场正在发生的大迁徙描绘了一幅清晰的路线图。报告中的数字是惊人的：

• 95% 的受访企业计划减少其 VMware 份额。
• 33% 的企业计划完全停止使用 VMware。
• 44% 的企业在续签 ELA（企业许可协议）时，成本增长超过了 100 万美元。

这已经不是零星的抱怨，而是一场由商业驱动的、不可逆转的技术浪潮。一个核心问题摆在了所有架构师面前：当企业决定“逃离” VMware 时，那些承载着核心业务的虚拟机（VMs），将何去何从？

答案，正日益清晰地指向一个我们既熟悉又陌生的方向：Kubernetes。

云原生的新常态：从“试验田”到“核心区”

在讨论 VM 的“新家”之前，我们必须先认清一个事实：Kubernetes 早已不是那个只运行无状态 Web 应用的“试验田”了。

报告数据显示，云原生已经成为企业构建未来的默认选择。82% 的新应用将在云原生平台上构建，更重要的是，58% 的企业已经开始在 Kubernetes 上运行他们最核心的 Tier 0/1 级别的任务关键型应用。

这意味着，Kubernetes 已经赢得了企业在性能、稳定性和数据安全方面的信任。它已经成功承载了：

• 69% 的数据库
• 67% 的实时分析系统
• 60% 的 AI/ML 应用

可以说，Kubernetes 已经“身经百战”，证明了自己有能力处理最复杂、最重要的数据密集型工作负载。这为它成为传统 VM 的下一个归宿，奠定了坚实的基础。

VM 的两条“出路”：现代化 vs 统一管理

当企业决定将 VM 工作负载迁出 VMware 时，报告揭示了两条并驾齐驱的主要技术路线：

1. 路径一：彻底现代化 (Modernize) – 59% 的选择

这是最“纯粹”的云原生路径：将传统的、运行在 VM 中的单体或分层应用，进行重构，将其彻底容器化。这条路的好处是能最大化地享受云原生带来的弹性、敏捷性和可移植性。但挑战也最大，它需要大量的重构工作，成本高昂且周期漫长。

2. 路径二：统一管理 (Consolidate) – 57% 的选择

这是一条更务实、更具变革意义的路径：不改变 VM 本身，而是将 VM 的管理平面，统一到 Kubernetes 之上。

通过使用 KubeVirt（报告指出 Red Hat OpenShift Virtualization 是市场首选）等技术，开发者可以在同一个 Kubernetes 集群里，像管理 Pod 一样，去声明、部署、运维和监控传统的虚拟机。

这一趋势，标志着 Kubernetes 的角色正在发生一次深刻的进化：它不再仅仅是一个“容器编排器”，而是在向“数据中心的通用控制平面”演进。 它旨在用一套统一的、声明式的 API，来管理数据中心里的一切——无论是现代的容器，还是“陈旧”的虚拟机。

新战场的挑战：当 VM 跑在 K8s 上

这场宏大的技术迁徙，并非一路坦途。报告同样揭示了这条路上最难啃的几块“硬骨头”：

• 最大的挑战是人：技能差距 (Skills Gap) – 61%
  传统的 vSphere 管理员面对的是熟悉的图形化界面，而 Kubernetes 的世界则是由 kubectl、YAML 和复杂的命令行构成的。这要求整个基础设施团队进行一次彻底的知识体系和运维模型的迭代，挑战巨大。

• 最硬的骨头是数据：存储 (Storage) – 69%
  这是将有状态应用（包括 VM）迁移到 Kubernetes 上的永恒难题。VM 习惯于稳定、高性能的块存储（如 vSAN、VMFS）。如何在 Kubernetes 的动态环境中，为 VM 提供企业级的存储、数据保护和灾难恢复能力，是最大的技术挑战。报告中提到，85% 的企业希望在 K8s 上能复制他们现有的存储架构，这个需求清晰而迫切。

• 迁移比想象的更难
  报告对比了 2024 年和 2025 年的数据，发现企业完成迁移的预期时间正在普遍推迟。例如，预期在 2027 年前完成迁移的比例，从去年的 83% 下降到了今年的 67%。这 16 个百分点的下降，无声地诉说着这场迁移的复杂性和艰巨性。

小结

由商业决策引发的技术变革，往往最为迅猛和彻底。企业“逃离” VMware，背后是成本压力、现代化需求和摆脱厂商锁定的多重驱动。

在这场浪潮中，Kubernetes 凭借其开放、可扩展和业已成熟的生态，正在成为承接这场“大迁徙”的最终目的地。它正在成为现代基础设施的通用操作系统，统一管理着从最新的云原生应用，到最传统的虚拟机的一切。

对于我们工程师而言，这意味着一个明确的信号：理解如何在 Kubernetes 上管理有状态应用和虚拟机，将不再是一项边缘或小众的技能，它正迅速成为云原生时代一项不可或缺的核心竞争力。 无论你选择帮助企业“现代化”应用，还是选择在 K8s 上“统一管理”VM，未来的机遇，都蕴含在这场波澜壮阔的技术变革之中。

资料链接：https://www.cncf.io/blog/2025/08/02/what-500-experts-revealed-about-kubernetes-adoption-and-workloads/

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。

本文永久链接 – https://tonybai.com/2025/08/03/choose-boring-technology

大家好，我是Tony Bai。

大约十年前，Dan McKinley 的一篇经典雄文《选择无聊的技术》（Choose Boring Technology）在工程师圈子里广为流传。它的核心观点简单而深刻：一家公司的“创新代币”（innovation tokens）是有限的，应该用在刀刃上，而不是随意挥霍在那些闪亮但未经证实的新技术上。

“无聊”的技术，比如 Postgres、Python、PHP，它们的优势不在于新潮，而在于其故障模式和能力边界是众所周知的。当系统在凌晨三点崩溃时，你需要的是一个有大量 Stack Overflow 答案可以求助的领域，而不是一片你必须独自开拓的未知“无人区”。

这个原则，在过去十年里，成为了无数资深工程师的技术选型座右铭。然而，十年后的今天，随着 LLMs 和 Agentic AI 编程工具的崛起，业界仍然认为：这个原则不仅没有过时，反而比以往任何时候都更加重要，甚至更加致命。

AI 时代的“诱惑”与“危险”

AI 编程助手带来了一个全新的变数。这个变数既有趣，又极其危险。

这里的“有趣”在于，现代 AI 工具（无论是 Claude 还是 Copilot）已经非常擅长为几乎任何你能想到的技术栈，生成“看起来非常专业”的代码。你给它一个 prompt，让它用最新的 JavaScript 框架、GraphQL federation 和 Kubernetes 来实现一套微服务，它会迅速给你返回一堆代码——这些代码可能遵循了所有社区惯例，命名规范无可挑剔，错误处理看起来也像模像样，甚至，它可能真的能运行。

这就是 AI 的“诱惑”。它让你感觉，掌握任何新技术都不过是弹指一挥间的事。

而“危险”也恰恰源于此。当你在一个你不熟悉的技术领域里使用 AI 时，一个致命的问题出现了：

你根本无法验证，AI 是不是在“一本正经地胡说八道”（bullshitting you）。

我亲眼见过，有工程师接受了 AI 生成的代码，而这些代码里：

• 使用了早已废弃的 API。
• 实现了严重的安全反模式。
• 制造了只有在生产负载下才会暴露的、极其隐蔽的性能问题。

为什么会这样？因为这些代码“看起来是对的”。但它的错误，是深植于技术细节中的，只有真正熟悉这门技术的人才能一眼看穿。

风险的“乘法效应”

过去，我们说选择一门新技术是增加了一个“未知数”。而在 AI 时代，当你将不熟悉的技术与 AI 生成的代码结合时，你不再是简单地增加未知数，而是在乘以未知数。

你不知道这个框架是否是解决你问题的最佳选择；你不知道 AI 的实现是否遵循了最佳实践；你不知道生成的代码中，哪些是无伤大雅的模板，哪些是核心业务逻辑；你更不知道，这套组合拳将会以何种奇特的方式在未来失效。

这已经不是简单的“货物崇拜”（cargo-culting）了，这是指数级的货物崇拜。

注：“货物崇拜”（cargo culting）是一个源自太平洋岛屿的概念，最早用于描述一些岛屿居民对西方物资和技术的崇拜现象。在二战期间，许多西方士兵在这些岛屿上驻扎，带来了大量的物资和现代技术。当地人对这些物品产生了强烈的向往，认为这些物品是神灵的恩赐。

AI 时代的“技术选型第一性原理”

那么，我们该怎么办？答案出奇地简单，它让我们回归到了那个最朴素的原则：

AI 是你所理解技术的“力量倍增器”，却是你不理解技术的“脆弱拐杖”。

当你选择“无聊”的技术，也就是你真正精通的技术时，AI 会变得无比强大。你可以让 Claude 帮你生成 Rails 代码，因为你对 Rails 了如指掌，能轻易发现它何时提出了可疑的建议。你可以让 Copilot 辅助你写 JavaScript，因为你理解这门语言的怪癖，能对它的产出进行事实核查。

在这种模式下，AI 是你的副驾驶，为你处理繁琐的路线，而你始终掌握着方向盘。

给 AI 时代开发者的实践指南

那么，在一个充满 AI 编程助手的世界里，我们该如何应用“选择无聊的技术”这一原则呢？这里有三条黄金法则：

1. 评估新技术时先自问：“如果 AI 为它生成了代码，我有能力审查吗？” 如果答案是否定的，那么这项技术或许不应该用于任何对你而言是任务关键型（mission-critical）的项目。

2. 学习新技术时（当你决定用掉一个“创新代币”时）： 请务必花时间深入理解它，达到能对 AI 的建议进行独立事实核查的程度。不要只是复制、粘贴，然后祈祷好运。

3. 抵制诱惑： 不要把 AI 工具当作一个借口，让你能同时拥抱一门新语言、一个新框架和一套新基础设施。AI 可能会给你一种“我能搞定一切”的错觉，但你无法真正验证其中任何一环。

小结：理解，是前所未有的宝贵资产

“选择无聊的技术”这个论点的初衷，是为了降低系统的运维复杂性和团队的认知开销。在 AI 时代，这些理由依然成立，但我们又增加了一个更重大的风险：对抗由 AI 带来的、致命的虚假自信。

如今的风险更高了，因为 AI 生成的代码质量越来越好，使得发现问题变得更加困难。过去，坏代码通常看起来就很糟糕。现在，有问题的代码可能看起来相当不错，直到你对该领域足够了解，才能注意到那些微妙的致命伤。

所以，我的建议始终不变：当你要解决一个问题时，请使用你已经了解的技术。当你想要学习新东西时，那就专心去学习。不要将 AI 生成的代码，误认为是真正的理解。

在一个 AI 可以自信地为你从未用过的技术生成数千行代码的世界里，你自己的、深刻的理解，比以往任何时候都更有价值。

资料链接：

• https://mcfunley.com/choose-boring-technology
• https://www.brethorsting.com/blog/2025/07/choose-boring-technology,-revisited

你的Go技能，是否也卡在了“熟练”到“精通”的瓶颈期？

• 想写出更地道、更健壮的Go代码，却总在细节上踩坑？
• 渴望提升软件设计能力，驾驭复杂Go项目却缺乏章法？
• 想打造生产级的Go服务，却在工程化实践中屡屡受挫？

继《Go语言第一课》后，我的《Go语言进阶课》终于在极客时间与大家见面了！

我的全新极客时间专栏 《Tony Bai·Go语言进阶课》就是为这样的你量身打造！30+讲硬核内容，带你夯实语法认知，提升设计思维，锻造工程实践能力，更有实战项目串讲。

目标只有一个：助你完成从“Go熟练工”到“Go专家”的蜕变！ 现在就加入，让你的Go技能再上一个新台阶！

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。如有需求，请扫描下方公众号二维码，与我私信联系。