軟體的宿命，最終都是走向死亡。
編譯 | 王啟隆
出品丨AI 科技大本營（ID：rgznai100）
K8s 最早的 MVP，大概花了不到一週就寫出來了。
幾個人，幾台機器，一個很粗糙的 demo：能把容器分發出去，能做最基礎的負載平衡，程序掛了能自動拉起，升級時能從 v1 切到 v2。放到今天看，這樣的開場甚至有點寒酸。很難把它和後來那個改寫了雲端原生格局、幾乎重塑了整個雲端運算語言體系的 Kubernetes 聯想在一起。
但這段歷史最值得回顧的，恰恰不是 Kubernetes 後來如何成為事實標準，而是它在最開始為什麼必須被做出來，而且必須開源。
今天看到 Brendan Burns（Kubernetes 聯合創始人，後來參與創辦了 Heptio，如今在微軟 Azure 擔任 Technical Fellow / CVP）的最新訪談，最有趣的地方，不是他又覆述了一遍 Kubernetes 的成功史，而是他把很多人默認已經寫進歷史的事情，重新拉回到了那個還沒有結果的時刻：
Kubernetes 最初只是一個幾天拼出來的 demo，但 Brendan Burns 當時就已經意識到：這種東西不可能永遠只屬於一家雲端供應商
Google 開源 Kubernetes，不是因為理想主義，而是因為最現實的判斷：你不做，別人也會做，而且你會失去定義它的機會
Kubernetes 後來統一了整個雲端原生生態，但在 Brendan 看來，它最值得回顧的，反而不是崛起，而是它總有一天也會退場
真正成熟的基礎設施，往往不是突然死掉，而是像 Linux 一樣，活著，卻越來越少被單獨討論
AI 時代最可能發生的，不是 Kubernetes 被正面擊敗，而是它被埋進更深的一層，變成預設存在、但不再被看見的系統地基
以下為這場對話的全文翻譯。
Google 為什麼非做 Kubernetes 不可？
Q：如果當年你要向 Google 管理層解釋，為什麼要為整個產業去做 Kubernetes，你會怎麼說？
Brendan Burns：其實早期最難的部分，不是把專案做出來，而是把這件事講明白。
在我們自己腦子裡，這件事很清楚，但怎麼把它說到足夠有說服力，讓別人也認同，並不容易。我們當時大概是從幾個角度去講。
一個很重要的背景，是 MapReduce 的教訓。那時候 Hadoop 和所謂的大數據革命都很熱。Google 寫了最早的 MapReduce 白皮書，但後來真正被產業廣泛採用的，是 Hadoop 這個開源實作。Google 提出了最初的想法，可生態並沒有圍著 Google 轉。別人讀了你的論文，做了一個相似但不完全相同的系統，最後真正跑起來、真正被大規模使用的，不是你的東西。
所以當時一個核心判斷就是：如果 Google 只是繼續發白皮書，而不把東西做成一個別人真的能跑、能部署、能用的系統，那就不可能真正站在技術演進的駕駛座上。
再往下，就是為什麼會是容器，而不是繼續圍繞虛擬機器做文章。我們的判斷是，隨著軟體越來越成為關鍵基礎設施，大家一定會需要一種「自動駕駛」式的系統去管理應用程式。我們在 Google 內部已經很清楚，想把複雜軟體穩定跑起來，不能只靠人盯著，必須有系統幫你處理部署、調度、恢復這些事。這個需求不是可有可無，而是軟體複雜度走到一定階段後，一定會出現的東西。
真正最有趣的，是最後那個問題：為什麼一定要開源？
很多人會說，你已經說服我這東西值得做了，那為什麼不把它做成 Google Cloud 獨佔的能力？這樣不是更有商業價值嗎？
可我們的判斷恰恰相反。因為如果你把它做成一個只在自己平台上能用的東西，你反而贏不了。這個世界上還有很多用戶不在你的平台上，他們在別的雲端上，也可能在本地機房裡。如果你把這些人全擋在外面，他們不會等你，他們只會自己再做一個替代品。
開源生態之所以經常能贏，就是因為它能在更多地方運行。Linux 為什麼能贏？很重要的一點，就是它可以去任何地方。對 Google Cloud 來說，如果你本來就不是市場第一，就更不能把這種東西做成封閉武器。你得讓所有人都能用它，再確保它在你的平台上最好用。這樣即便別人不在你的平台上，他們也會先聽你怎麼定義問題、怎麼講這個方向。
說得更直接一點：反正這個世界一定會出現一個開源版本。問題只是，這個開源版本到底是你做，還是別人做。
Q：所以從商業上說，Google 當時是想藉 Kubernetes 改變雲端運算的競爭格局？
Brendan Burns：對，這是很重要的一部分。
如果市場上已經有人把虛擬機器這套東西做成主流，而你能講出的故事只是「我們也有一套類似的，只是在某些地方更好一點」，那其實很難。你會一直活在別人的敘事裡，一直在追別人的車尾燈。
但如果你定義了一塊新戰場，情況就完全不一樣了。你不再只是追趕別人，而是開始由你來組織問題、組織語言。即便別人最後沒有直接跑在你的平台上，他們也會先把注意力放到你這裡，因為這個方向是你先講出來、先做出來的。
這種「話語權」很難量化，但它非常重要。它改變的是整個市場裡誰在定義未來，誰在主導敘事。
當然，今天回頭看，Google Cloud 也沒有因為 Kubernetes 一下子變成市場第一，所以你不能把這件事講成一個簡單的商業勝利故事。但 Kubernetes 的確把 Google 放到了雲端原生時代最核心的話語位置上，這一點我覺得沒什麼可爭議的。
Q：你們最早做出來的那個 demo，到底是什麼樣子？
Brendan Burns：其實非常簡單。
大概就是一個最基礎的控制介面，能把容器部署出去，能把它分發到幾台機器上，也能做一點很基礎的負載平衡。比如你訪問同一個入口，它會告訴你「我是副本 1」，重新整理一下可能又變成「我是副本 3」，藉這個讓你看到，它確實已經被複製並且分散到不同機器上了。
另外還有很基礎的健康檢查。你把程序殺掉，它能重新拉起來。再加上一個很初級的版本升級演示，能從 v1 切到 v2。差不多就是這些。
今天回頭看，這當然很原始，談不上什麼完整產品。但對說服別人來說已經夠了。因為那不是一頁 PPT，也不是一份概念文件，而是一個真實能跑起來的東西。
一個不到一週做出的 demo，後來改寫了雲端運算
Q：這個最初的 MVP，花了多久做出來？
Brendan Burns：不到一週吧，大概四五天。
當然，那真的是一個「能省的都省了」的版本。所有能走的捷徑都走了。很多底層能力也不是從零開始自己造，而是盡量借助現成的開源專案，把能拿來的東西拿來，再用一些膠水程式碼把它們黏起來，先讓系統具備基本的樣子。
我過去一直比較擅長的一件事，就是看怎麼把已有的開源元件整合成一個新的系統。這種能力在 Kubernetes 最早那個階段特別關鍵。因為早期原型的價值，從來不是優雅，而是盡快讓別人看到：這件事是成立的，是跑得起來的。
Q：你當時不是也有自己的正式工作嗎？這種專案怎麼騰出時間做？
Brendan Burns：我不會說自己把原來的工作完全扔了，但在那麼短的時間尺度裡，其實是可以挪出空間的。
我一直有一句有點「危險」的建議：我相信，大多數人都能從自己的工作裡「藏出」大概 10% 的精力，而不被管理層真正察覺。
我的意思不是讓人偷懶，而是說，在大多數組織裡，你其實總能保留一點點自由度，去做一些沒人明確讓你做、但你自己覺得重要的事。很多真正有影響力的想法，都是從這種空間裡長出來的。
當然，這背後也有一個前提：你得接受失敗。
你去做這種 side project，很多時候不會成功。你可能投入了時間，最後什麼都沒發生；你也可能因為把精力押在一件不確定的事上，而少做了一些更容易被看見、被評價的工作。你得接受這種風險，接受「試五次，成一次，但那一次的回報可能遠大於前面四次」的邏輯。
有些人適合這樣做，有些人不適合，這都很正常。
還有一個更直接、也更現實的事實是，很多人會說自己沒有時間做這些額外專案，但他們一週裡很可能還是會花十幾個小時打遊戲、滑 YouTube、看 Netflix。那最後其實不是有沒有時間的問題，而是你願不願意為了自己真正相信的事，放棄什麼。
我不是那種鼓吹天天熬夜工作的人，但如果你真的覺得某件事重要，那有時候就意味著，你會在一段時間裡少看點影片，少做點別的娛樂。
Q：所以你的方法不是先寫文件爭取許可，而是先把東西做出來？
Brendan Burns：對，差不多就是這樣。
很多事情很難靠文件解釋清楚。你可以寫一份策略說明，也可以做一套 PowerPoint，但真正有效的方式，往往還是先拿出一個能跑的東西。只要它開始運行，討論的性質就會發生變化。
如果你什麼都還沒做，管理層面對的問題是：要不要把時間和資源押給這件事。但如果你已經把東西做出來了，哪怕還很粗糙，問題就會變成：這個東西值不值得繼續推進、值不值得發布。
這兩種討論，完全不是一回事。
前者討論的是資源分配，後者討論的是這個想法本身是不是成立。對很多新專案來說，從前一種問題切換到後一種問題，本身就是一個決定性的進展。
當然，這裡面依然有失敗風險。你可能花了時間把東西做出來，最後大家並不買帳。但如果你要做這種事，就得把這一點一起吞下去。你不能只接受成功的可能性，卻不接受失敗的代價。
Brendan Burns 的工程方法論，其實比 Kubernetes 本身更值錢
Q：從那個原型，到真正能讓別人拿來試用，中間隔了多久？
Brendan Burns：大概半年。
從一個非常 hacky 的原型，到一個我們覺得別人真的可以拿去嘗試的系統，中間還有大量基礎工作要補。很多看起來不起眼的細節，最後都得一項項做紮實。
但那個階段其實也很珍貴。因為你幾乎是在一個「乾淨房間」裡重做一套系統。很多後來加入的人，本來就在別的地方做過類似系統，腦子�早就積累了一堆「如果讓我重來一次，我會怎麼設計」的想法。
可現實世界裡，很少有工程師真的能得到這種機會。
更多時候，你接手的是一個已經上線、有大量用戶、有既有包袱的系統。你每天都在修 bug、兼容歷史問題、給舊設計打補丁。真正從零開始、在歷史債務相對少的情況下重建一套系統，是工程職業裡非常稀缺的時刻。Kubernetes 早期恰好有這樣一個視窗。
Q：今天很多工程師聽這種故事，第一反應可能是：這畢竟是 Google，我在現實裡哪有這樣的空間？
Brendan Burns：組織環境當然會有差異，但這裡面也有一個個人選擇的問題。
很多人會把「沒有空間」理解成一個絕對條件，可現實更像是：空間很小，風險很高，而且沒有人會保證你做的事一定值得。你得自己判斷，自己下注，自己承擔不成的後果。
而且從職業發展上看，越往上走，這種能力反而越重要。因為在更高層級裡，很少還有人會把一個足夠讓你完成躍遷的專案，包裝好、定義好、直接交到你手上。更多時候，真正重要的專案，是你自己看到、自己提煉、自己把它推出來的。
從這個角度看，所謂 side project，不只是「業餘愛好」，它其實也是在訓練一種更主動的工程視角和職業能力。
K8s 也會死，只是死法可能和你想的不一樣
Q：Kubernetes 今天已經成了事實標準，它會不會也有自己的上限？
Brendan Burns：當然會有，但關鍵在於你怎麼理解這個「上限」。
Kubernetes 的很多元件，本質上都可以橫向擴展。請求變多了，可以加 API Server；調度壓力大了，可以加調度器。很多部分都可以透過 scale out 來解決。
真正更難的，還是底層儲存層。因為在 Kubernetes 的架構裡，大量狀態最終都會回到那裡，真正不那麼容易無限擴展的，也往往是這一層。今天大家熟悉的是 etcd，如果未來規模繼續往上推一個數量級，就得重新回答：它還能不能承受？還是說，需要一個保留相同核心特性、但擴展能力更強的方案來替代它？
我不認為 Kubernetes 在設計上存在一個天然寫死的天花板，阻止它繼續擴展。但系統一旦跨過一個數量級，問題就會遷移。原先最顯眼的瓶頸，可能突然變得不再重要，新的瓶頸會在別的地方浮出來。你原先受限於 CPU，後來可能變成受限於網路；你原先受限於記憶體，後來可能變成受限於儲存。每跨過一個數量級，真正的問題都會移動。
Q：你說過一句話，軟體的宿命是死亡。那 Kubernetes 也會死嗎？
Brendan Burns：我完全認同這句話。
不過更完整的說法其實是：你最好別愛上自己的軟體，因為軟體不可避免的軌跡就是死亡。真正想表達的是，不要因為「這是我寫的」就捨不得放手。當它該被替代的時候，你就應該願意把它扔掉。
從產業歷史來看，這幾乎是普遍規律。哪怕在 Kubernetes 內部，我當年寫的很多程式碼，後來也已經被重寫很多次了。
至於 Kubernetes 會怎麼「死」，未必一定是突然被另一個新系統徹底替代。有時候，一個系統並不會真的消失，而是會變得越來越底層、越來越隱形。就像今天 Linux 還在，但大多數人不會天天討論 Linux；處理器架構也還在，但不是所有開發者都時刻盯著它。
Kubernetes 也可能走向這種狀態：它還在，只是被更上層的系統蓋住了，被新的互動方式包起來了，最後人們越來越少直接感知它。
尤其在 AI 時代，很多注意力已經轉向模型、推理框架和應用介面，Kubernetes 可能慢慢退到底層，成為那個預設存在、但不再是主角的能力。
當然，如果把時間拉到足夠長，比如一百年後，我會非常驚訝 Kubernetes 還能原封不動地存在。技術世界變化太快了，很多今天看起來堅固的東西，幾年後就可能開始鬆動。未來最大的問題，從來不是你沒預測到變化，而是變化來得比你想像更快，或者根本不是你以為的那個方向。
關鍵是「記好筆記」
Q：你怎麼看讀 PhD 這件事？很多人會糾結到底值不值。
Brendan Burns：這是別人最常問我的問題之一。
如果只從職業回報率來看，我可以講一個很現實的故事。我後來在同一家公司裡遇到過一個大學同學。我們同年畢業，他去創業、進產業界，我去讀了 PhD，後來又回到產業界。結果我們最後在公司的層級是一樣的。
所以如果你問我，讀 PhD 會不會讓你在職業發展上顯著領先，我的答案大概是：未必。很多時候，其實差別沒那麼大。
但如果反過來問，這段經歷值不值，我又會說：對我來說值，因為我玩得很開心，而且學到了很多非常有用的能力。
比如寫作和表達。博士訓練和指導教授對我的影響，讓我學會了怎麼把一個複雜想法寫清楚、講清楚。後來 Kubernetes 早期那段時間，我們花了很久去推動、去說服、去爭取內部支援，這種能力其實非常重要。
另外，我後來還做過幾年教授。給完全不懂電腦的人上課，會逼著你去思考：你到底該怎麼把一個複雜系統講到別人能懂。Kubernetes 早期也一樣，很多人會問：什麼是容器？什麼是 orchestration？我為什麼需要它？這些問題都不是你把程式碼寫出來就自動解決了的，你必須會教，必須會解釋。
所以如果你問我，我會說：PhD 不一定讓你在頭銜上更快領先，但它可能會給你一些長期非常有價值的能力。
Q：年輕工程師最常問你的另一個問題是什麼？
Brendan Burns：另一個很常見的問題是：我到底該學什麼？
比如現在 AI 很熱，但有些人自己更喜歡系統，就會來問我：那我是不是應該放棄系統去學 AI？我的回答通常是，我沒那麼在乎你學的具體是什麼，我更在乎你是不是在持續學習。
如果你對 AI 根本沒熱情，只因為它熱門就硬學，那你多半也學不好。反過來，如果你真的喜歡系統，你會投入更多時間和注意力進去，而這種持續投入更有可能轉化成真正的能力。產業也永遠不會不需要優秀的系統工程師。
我能感受到，很多年輕人特別害怕「選錯方向」。但說實話，我自己從來沒有一條嚴密的人生規劃。我一直都是看什麼東西有意思、有價值，就去追。
當然，這種方式也可能有風險，但我也想提醒大家：很多你事後覺得是在繞路的經歷，最後恰恰可能變成最重要的養分。只要你一直在學，通常就不會太差。
Q：有沒有哪本書，對你的職業影響特別大？
Brendan Burns：如果是在工程師階段，對我影響很大的一本書是《Design Patterns: Elements of Reusable Object-Oriented Software》，也就是大家熟悉的 GoF《設計模式》。
後來隨著角色變化，開始帶更大的團隊，我會更推薦另外兩本：一本是《Leadership on the Line》，另一本是《The Five Dysfunctions of a Team》。
前者更偏領導力，後者更偏團隊協作。大致可以這麼理解：如果你現在主要還是工程師，先讀《設計模式》；如果你已經開始做管理或組織領導，後兩本會更有幫助。
Q：如果回到剛大學畢業的時候，你會給當時的自己什麼建議？
Brendan Burns：記更好的筆記。
我一直覺得，Kubernetes 這一路的經歷，其實完全值得寫成一本書，甚至能寫出一篇很好的商業案例。但問題是，我當年沒有留下足夠完整的記錄。
程式碼當然還在，但真正容易消失的，往往不是程式碼，而是那些關鍵時刻的討論、夥伴之間的拉扯、組織內部的推動、管理人與人之間的判斷和博弈。這些我現在還記得一部分，但已經記不全了。
如果當年能留下更完整的筆記，今天回頭看，一定會很有價值。