如果你所在的企業引入了 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）分心 —— 把它留給家庭實驗室吧。