如果你所在的企业引入了 Kubernetes，那么你们很有可能会把精力花在一些偏离主线的事情上。

　　乍一听这句话可能会感觉到很奇怪，毕竟我们花了这么长的时间来布道和兜售 Kubernetes 的发行版以及咨询服务，致力于帮助人们能够更加充分地利用它，但是事情就是这样！你也许不应该针对你的产品使用 Kubernetes 以及其他一堆“酷”的东西。

　　绝大多数的初创以及扩张阶段的企业在构建软件时都应该避免使用 Kubernetes 以及其他的一些过早优化。如果你所在的企业使用了 Kubernetes，那么你们很有可能会把精力花在一些偏离主线的事情上。你们可能已经跌入了过早优化的陷阱。

　　请不要觉得这篇文章只是针对 Kubernetes。不是的。这篇文章针对的是工程师们在构建软件的过程中可能做出的所有过早优化。

　　以下是我见过的一些例子：

　　将 Kubernetes 用于一个应用（还是个 Web 应用）的企业；

　　应用程序用到了不只一种语言。比如，后端用的是 Golang、Ruby 或者是 PHP 等语言，然后前端 Web 用的是 React 或者 Vue 等框架；

　　没有用云服务来托管应用。比如可以用 Heroku、Vercel、Netlify 或者 Fly.io 等。对于绝大多数产品团队来说，如果他们必须组建一个运维或者基础架构团队的话，他们的解决方案也将会是过度设计的。

　　试想一下，一个人在真正开始玩他的爱好之前花费了大量的时间和金钱为这个爱好挑选最好的装备。

　　当然，这里面有一些观点是比较主观的。也许你知道你会长期坚持你的新爱好，而且你有一个朋友刚好是这方面的行家，他可以帮你挑选合适的装备。不得不说，我自己就很擅长为自己辩解为什么要挑选精英装备，尽管我可能永远不会真的注意到这其中的区别。

　　— 1 —

　　好钢要用在刀刃上

　　如果你所在的企业认为它需要 Kubernetes，那么你也许正处在一个试图过早地为未来优化的地方。一个可能永远不会出现的未来。当你采用任何一项技术时，换个角度，也即是在为你所在的组织作出一个有效期长达数年的承诺，这将会增加产品的表面积，同时也会给开发人员带来心智负担。

　　最终，你将不得不组建一个专门的团队来维护它。这一切都会从你的核心使命里夺走资源。

　　工程师们很容易跌入这个陷阱。我们很容易被新兴的炫酷技术分散注意力。我们想要学习和成长，而实现这一点的最佳途径就是把最新的技术融入到我们的产品里。然后，我们会想出各种理由来证明我们的决定是合理的。

　　我来给你们讲几个故事吧，关于我是如何跌入这个陷阱的。

　　我记得在我刚加入 OCUS 的时候我们有过一次讨论，我发现我们当时正在使用 Kubernetes。我说了一些话，类似于，“哦，那太好了。万一有一天我们如果想要弃用 AWS ，那么引入 Kubernetes 刚好可以帮助我们解决这个问题”。你能看出当时我有多疯狂吗？

　　还有一次，我们的数据科学团队告诉我们，他们的数据管道需要一个编排工具。我倾向于选用 Argo Workflow（它跑在 Kubernetes 里），而不是他们已经做了 PoC 的 Perfect（一款 SaaS 产品）。对于这个决定，我可以给出种种理由。

　　不幸的是，它们都是基于过早优化的前提。故事的最后，我们的团队需要去构建一组新的 Terraform 和 Helm Chart 来自动化部署 Argo Workflow，然后把它集成到我们的 SSO 等等。对于这个决定我感到很遗憾。我认为正是由于做出了这个决定，这导致我们延误了数周甚至数月的时间才向最终用户交付功能。这就是过早优化！

　　如果我们能够避免过早优化，我们将可以比竞争对手更快地行动，取悦我们的用户，构建一套可持续和可行的产品的可能性也会提高。

　　那么我们怎样才能打破这种思维呢？

　　— 2 —

　　用户有没有提这个要求？

　　解决沿途遇到的问题而不必再提前考虑。我们所做的工作都应该切实地解决用户的问题。问问自己，我试图通过我的工作影响哪些人类行为？

　　如果你可以始终专注于用户行为，并且只解决那些它们自己冒出来的实际问题，那么你将会对自己产生的影响力感到惊讶。你也许还会对自己曾经向用户作出的诸多假设感到惊讶，因为你已经很久没谈论这些了。

　　我相信，严格坚持这种方法的企业将会为他们的用户和股东们创造更大的影响力并且产生更多的价值。

　　如果我把所有的精力都倾注在我的新爱好而不是研究设备上，那么我自然会知道我想要的到底是什么。在起步阶段，我并不需要最 “Gucci” 的装备，即便我有最好的装备，我甚至也会因为不知道如何使用它而显得格格不入。最好是用一套入门级设备来碾压别人，因为我所有的精力都用在了学习我的新爱好上。然后当我确实想要升级到 “Gucci” 装备时，它就会真的变得不同凡响。

　　— 3 —

　　事半功倍

　　值得庆幸的是，科技界正在经历一场大规模的路线修正。随着利率上升，廉价债务和风险资本开始枯竭。现如今的初创企业再也无法获得疯狂的资金，他们必须更加专注于他们的使命。能够生存下来的将是那些拥有坚实基础的企业。

　　产品必须交给那些能够以越来越快的速度交付业务成果的更小团队来构建。

　　在 Kubernetes 完全普及之前，我无法预见到 Kubernetes 在一个精益组织中的位置。即便如此，我认为 Kubernetes 还是可以当作一个扩展引入的。大多数组织可以考虑通过云厂商提供的一些更高层面的构建块来引入它。

　　别忘了，在 Facebook 以 190 亿美元收购 WhatsApp 时，它只有 35 名开发人员却服务了 4.5 亿用户！

　　如果要问本文给读者的忠告是什么的话，我想应当会是：高度关注实现组织使命所需的内容。不要被你想学习的东西（比如 Kubernetes 或 Golang）分心 —— 把它留给家庭实验室吧。

　　如果你所在的企业引入了 Kubernetes，那么你们很有可能会把精力花在一些偏离主线的事情上。

　　乍一听这句话可能会感觉到很奇怪，毕竟我们花了这么长的时间来布道和兜售 Kubernetes 的发行版以及咨询服务，致力于帮助人们能够更加充分地利用它，但是事情就是这样！你也许不应该针对你的产品使用 Kubernetes 以及其他一堆“酷”的东西。

　　绝大多数的初创以及扩张阶段的企业在构建软件时都应该避免使用 Kubernetes 以及其他的一些过早优化。如果你所在的企业使用了 Kubernetes，那么你们很有可能会把精力花在一些偏离主线的事情上。你们可能已经跌入了过早优化的陷阱。

　　请不要觉得这篇文章只是针对 Kubernetes。不是的。这篇文章针对的是工程师们在构建软件的过程中可能做出的所有过早优化。

　　以下是我见过的一些例子：

　　将 Kubernetes 用于一个应用（还是个 Web 应用）的企业；

　　应用程序用到了不只一种语言。比如，后端用的是 Golang、Ruby 或者是 PHP 等语言，然后前端 Web 用的是 React 或者 Vue 等框架；

　　没有用云服务来托管应用。比如可以用 Heroku、Vercel、Netlify 或者 Fly.io 等。对于绝大多数产品团队来说，如果他们必须组建一个运维或者基础架构团队的话，他们的解决方案也将会是过度设计的。

　　试想一下，一个人在真正开始玩他的爱好之前花费了大量的时间和金钱为这个爱好挑选最好的装备。

　　当然，这里面有一些观点是比较主观的。也许你知道你会长期坚持你的新爱好，而且你有一个朋友刚好是这方面的行家，他可以帮你挑选合适的装备。不得不说，我自己就很擅长为自己辩解为什么要挑选精英装备，尽管我可能永远不会真的注意到这其中的区别。

　　— 1 —

　　好钢要用在刀刃上

　　如果你所在的企业认为它需要 Kubernetes，那么你也许正处在一个试图过早地为未来优化的地方。一个可能永远不会出现的未来。当你采用任何一项技术时，换个角度，也即是在为你所在的组织作出一个有效期长达数年的承诺，这将会增加产品的表面积，同时也会给开发人员带来心智负担。

　　最终，你将不得不组建一个专门的团队来维护它。这一切都会从你的核心使命里夺走资源。

　　工程师们很容易跌入这个陷阱。我们很容易被新兴的炫酷技术分散注意力。我们想要学习和成长，而实现这一点的最佳途径就是把最新的技术融入到我们的产品里。然后，我们会想出各种理由来证明我们的决定是合理的。

　　我来给你们讲几个故事吧，关于我是如何跌入这个陷阱的。

　　我记得在我刚加入 OCUS 的时候我们有过一次讨论，我发现我们当时正在使用 Kubernetes。我说了一些话，类似于，“哦，那太好了。万一有一天我们如果想要弃用 AWS ，那么引入 Kubernetes 刚好可以帮助我们解决这个问题”。你能看出当时我有多疯狂吗？

　　还有一次，我们的数据科学团队告诉我们，他们的数据管道需要一个编排工具。我倾向于选用 Argo Workflow（它跑在 Kubernetes 里），而不是他们已经做了 PoC 的 Perfect（一款 SaaS 产品）。对于这个决定，我可以给出种种理由。

　　不幸的是，它们都是基于过早优化的前提。故事的最后，我们的团队需要去构建一组新的 Terraform 和 Helm Chart 来自动化部署 Argo Workflow，然后把它集成到我们的 SSO 等等。对于这个决定我感到很遗憾。我认为正是由于做出了这个决定，这导致我们延误了数周甚至数月的时间才向最终用户交付功能。这就是过早优化！

　　如果我们能够避免过早优化，我们将可以比竞争对手更快地行动，取悦我们的用户，构建一套可持续和可行的产品的可能性也会提高。

　　那么我们怎样才能打破这种思维呢？

　　— 2 —

　　用户有没有提这个要求？

　　解决沿途遇到的问题而不必再提前考虑。我们所做的工作都应该切实地解决用户的问题。问问自己，我试图通过我的工作影响哪些人类行为？

　　如果你可以始终专注于用户行为，并且只解决那些它们自己冒出来的实际问题，那么你将会对自己产生的影响力感到惊讶。你也许还会对自己曾经向用户作出的诸多假设感到惊讶，因为你已经很久没谈论这些了。

　　我相信，严格坚持这种方法的企业将会为他们的用户和股东们创造更大的影响力并且产生更多的价值。

　　如果我把所有的精力都倾注在我的新爱好而不是研究设备上，那么我自然会知道我想要的到底是什么。在起步阶段，我并不需要最 “Gucci” 的装备，即便我有最好的装备，我甚至也会因为不知道如何使用它而显得格格不入。最好是用一套入门级设备来碾压别人，因为我所有的精力都用在了学习我的新爱好上。然后当我确实想要升级到 “Gucci” 装备时，它就会真的变得不同凡响。

　　— 3 —

　　事半功倍

　　值得庆幸的是，科技界正在经历一场大规模的路线修正。随着利率上升，廉价债务和风险资本开始枯竭。现如今的初创企业再也无法获得疯狂的资金，他们必须更加专注于他们的使命。能够生存下来的将是那些拥有坚实基础的企业。

　　产品必须交给那些能够以越来越快的速度交付业务成果的更小团队来构建。

　　在 Kubernetes 完全普及之前，我无法预见到 Kubernetes 在一个精益组织中的位置。即便如此，我认为 Kubernetes 还是可以当作一个扩展引入的。大多数组织可以考虑通过云厂商提供的一些更高层面的构建块来引入它。

　　别忘了，在 Facebook 以 190 亿美元收购 WhatsApp 时，它只有 35 名开发人员却服务了 4.5 亿用户！

　　如果要问本文给读者的忠告是什么的话，我想应当会是：高度关注实现组织使命所需的内容。不要被你想学习的东西（比如 Kubernetes 或 Golang）分心 —— 把它留给家庭实验室吧。

　　如果你可以继续高度专注于对自己的产品进行迭代，以影响业务结果的方式影响人类行为，那么我毫不怀疑你将最终能够脱颖而出。