基礎設施 · Chapter 05
Apollo:
看不見的祕密武器
大多數人談 Palantir 只談 Foundry 與 AIP。但讓那些軟體能同時活在公有雲、客戶機房、與斷網軍艦上、還能持續更新的,是 Apollo——這是最難被複製的一塊。
Apollo 解的是第 01 章的第三個鴻溝:部署鴻溝。它是一套「約束式」的持續部署與運維系統,把 Palantir 所有產品自動送到成千上萬個環境,而且環境之間安全等級天差地別。
The Hard Problem為什麼這件事這麼難
主張:一般 SaaS 只需服務一種環境:自己的雲。Palantir 必須把同一套軟體同時交付到公有雲、客戶地端、政府機密雲、甚至完全斷網的環境——而且都要持續更新。這是絕大多數 SaaS 直接死掉的地方。
同一個 Foundry 版本,今天要上線到:AWS 商業雲(某銀行)、客戶自家 VMware 機房(某藥廠,法規不准上雲)、AWS GovCloud(某聯邦機構)、以及一艘網路完全隔離的軍艦。四種環境、四種安全邊界、四種合規要求。傳統做法要四組人手動維護四條發布線,每次更新都是災難。
The Mechanism約束式自主部署
主張:Apollo 不靠人工排程,而是靠宣告式的約束(constraints):你只描述「什麼狀態是安全/允許的」,Apollo 自主決定何時、以什麼順序把哪個版本推到哪些環境,並在出問題時自動回滾。
- 宣告約束「新版本必須先在 staging 跑滿 24 小時無錯,才能進 production」「金融客戶環境只能在維護窗口更新」。
- 自主編排Apollo 讀這些約束,自動把 v2.5 推到符合條件的環境,跳過還沒到窗口的。
- 偵測回滾某環境升級後錯誤率飆高,Apollo 自動回滾該環境到 v2.4,並暫停對其他同類環境的推進。
- 收斂幾千個環境最終各自收斂到「在其約束下允許的最新版」,全程幾乎無人介入。
Air-gapped更新一個「沒有網路」的系統
主張:Apollo 能把更新交付到與網際網路完全隔離的環境——這是純雲端 SaaS 架構上做不到的,也是 Palantir 拿下軍事/情報合約的硬前提。
一套 Palantir 系統跑在潛艦上,任務期間完全不連外網。更新透過受控媒介(實體介質或單向資料閘)帶進封閉網域,Apollo 在域內那一側自主完成部署、驗證、必要時回滾——就像在雲上一樣,只是這個「雲」是一個與世隔絕的盒子。這種能力,Snowflake、Databricks、乃至多數超大雲的受管服務都給不了。
Why It's a Moat為什麼這是護城河
De-mystification祛魅:這不就是 Kubernetes + ArgoCD?
攻擊
持續部署、金絲雀、自動回滾——這些 ArgoCD / Spinnaker / Flux 都有。開源就能做,Apollo 沒什麼神祕。
回應
在單一雲、你自己控制的環境裡,這說法對。差異出現在邊界:數千個你無法直接連線、安全等級各異、甚至斷網的第三方環境,要做到自主、可審計、可回滾的持續交付。這不是 ArgoCD 的設計場景。你當然能拿開源慢慢逼近——但那正是「買 vs 自建」的核心取捨,見第 08 章。