千萬不要過早引入Kubernetes

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

如果你可以繼續高度專注於對自己的產品進行迭代，以影響業務結果的方式影響人類行為，那麼我毫不懷疑你將最終能夠脫穎而出。