私有雲是如何產生的？
為了預見未來，必須了解歷史。
話說，自從 2006 年 AWS 發布第一個服務 S3 和 EC2 之後，這種 Web Services 的方式交付 IT 基礎設施資源的模式被人稱為公有雲，隨後 AWS 接近以平均每年接近 100% 的速度持續增長了 14 年。誰也沒有想到，當時一家以賣書為主的電商公司的 IT 業務竟然打敗了 IBM，思科，戴爾，微軟等一眾歷史悠久的 IT 巨頭。
這個世界最常見的一個規律就是二元對立，有「公」必有「私」，公有雲既然已經成形，而且一騎絕塵，發展太快，跟不上步伐，那必須得另闢蹊徑。於是私有雲的概念順理成章出來了。
私有雲有著非常強烈的現實需求，即使是 AWS 從發布至今 14 年之後，公有雲廠家競爭看上去已經白熱化的今天，公有雲的總支出只佔到總 IT 支出 3%（ 見下圖）。也就是說直到今天，全世界每生產 100 臺伺服器設備，有 97 臺將會被各企業放在自己管理的私有機房裡運行著。值得注意的事，這還是在以 AWS 為代表的公有雲出現 14 年之後的今天，公有雲消費仍然佔比如此小，也就是說在 10 年前，公有雲市場幾乎微不足道。
圖：AWS 2019 re:Invent Keynote by AWS CEO Andy Jessy
由公有雲爆發式增長引發了市場對「私有雲」巨大的想像空間，在這麼大的市場誘惑下，人們開始想像，如果有一套私有雲軟體，能夠把這些分散在企業自管的數據中心的伺服器等硬體資源整合起來，那將是個多麼大的生意。
私有雲簡史
於是，除 AWS 之外幾乎所有主流的 IT 公司都投入了建設私有雲這場大躍進運動中，都希望能在未來這個大市場中佔據一席之地。私有雲世界也經歷了三波發展：
第一波，是從 2008 年開始的一批私有雲軟體，其中以 Eucalyptus 和 CloudStack 為代表，後來因為單體架構和不夠開放等原因，沒有打開市場，市場注意力很快轉向 OpenStack。
第二波，是從 2010 年，以 OpenStack 為代表的開源社區及生態公司，開源基金會的治理方式解決了不夠開放問題，分而治之的面向服務的架構也解決了單體架構不夠靈活的問題，為了保證成功，OpenStack 服務的設計一直在模仿 AWS，早期甚至直接使用 AWS 原生的 API。OpenStack 早期不論是從頂層設計上還是在聲勢上來看，是最有成功的模樣，聚集了開源史上僅次於 Linux 生態的公司和開發者，也匯聚了無數私有雲創業公司的夢想。但在 2016 年之後，市場遲遲沒有打開局面，生態公司也幾乎沒有一家在商業化上取得像樣的成功，其影響力日漸式微。私有雲復興重任交給了Kubernetes。
第三波，是從 2014 年開始 Kubernetes 為代表的開源社區及生態公司。同樣的以開源基金會的治理方式，同樣是分而治之的面向服務的架構，只是這會充分吸取了前任的教訓，不再以 AWS 為原型來發展，因為活在巨人的陰影下總是很憋屈的。Kubernetes 並不學 AWS 以虛擬機為中心來構建服務群，而是藉助容器技術，解決應用開發者最關心的應用部署、運維、服務化等問題。無疑這個策略到目前為止，算是成功的。許多堅持不上公有雲的公司，在自有數據中心運行業務時，會首選 Kubernetes 來構建技術底層平臺。其實 K8S 與平臺無關，部署在哪裡都可以，部署在你自己的機房，你可以叫它私有雲，也可以部署在任何一個主流的公有雲，而且各公有雲還支持方便地接入 K8S 服務。
幾乎與公有雲的發展時間同步的 10 多年過程中，還伴隨著一眾自研的、或基於開源系統的商業公司，此起彼伏。但整個市場似乎一直止步不前，10 年前和 10 年後，客戶負責的數據中心的軟硬體變化不大，一樣的配方，一樣的味道，只是整個市場多了不少焦慮。
私有雲走著走著迷失了方向。
私有雲的反思
在私有雲經歷了這些波折，我們再回來看這個時候有公有雲的現狀：
圖：AWS 公有雲全球網絡骨幹拓撲 @ AWS 2019 re:Invent Keynote by Peter DeSantis
AWS 經過 14 年的建設全球一張網，覆蓋全球主要城市和地區。這只是網絡，更不用說已經發布的幾百個獨立服務，滿足幾乎所有行業、所有應用的需求。
AWS 14 年的優勢是累積效應，14 年來 AWS 只是在建設一個雲，服務幾百萬企業客戶，一年產生 300 億美金的收入，如此大體量仍然還能保持每年 2 位數的增長速度。
而同樣發展了 10 幾年的私有雲，一般由幾臺、幾十臺或更多機器組成的一個一個分散的、隔離的小雲，不斷地在重複造輪子，幾乎無法累積優勢。過去十幾年，市場上重複造了成百上千個私有雲，但每一個私有雲的建設幾乎都是諮詢式、定製化的，都需要經歷從需求調研、硬體選型、網絡設施、架構設計、實施部署等環節，每一個環節幾乎都不可能自動化，因為要上門，要進機房，要搬箱子，每一個環節不靠譜都可能導致項目失敗。
因此，到目前為止，沒有一家私有雲公司獲得了累積效應，都是在低水平線上不斷地重複。
發展到這裡，終於意識到，以公有云為標的來構建私有雲夢想根本不可能。雖然都被叫做雲，但是 2 個完全不同的世界和不同的物種。
Ok，私有雲的故事發展到這裡，似乎應該終結了。
AWS 的突襲
在私有雲起起伏伏十幾年的發展過程中，AWS 也一直拒絕承認私有雲是雲，甚至在自己的市場規範手冊中，不能提及私有雲、混合雲等關鍵詞。引導客戶上公有雲是 AWS 的使命。
然而，在 2018 年 re:Invent 大會發布 AWS 的私有雲產品 Outposts 預覽產品，到今年短短一年時間 Outposts 正式商用發布[2]，相關的技術細節也一同發布，當看到裡面的細節設計時，我是無比震驚的。
圖：AWS Outposts 機櫃實物照片
從官方頁面來看，這是一個機櫃式一體機，據多位現場技術人員反饋，Outposts 裡面使用的硬體平臺和軟體平臺跟 AWS 公有雲是完全一致的，包含了 AWS 最新的 Nitro 硬體平臺架構。 整體打包出租而不是一臺機器一臺機器的賣。更多細節介紹參考官網或特大妹的文章。
這裡重點總結一下 Outposts 在設計上的「與眾不同」，也是被吐槽最多的地方：
不支持出售，僅支持以整機櫃租賃模式。也就是說，機器的所有權屬於 AWS，不屬於用戶。
不支持自帶硬體，只能使用全 AWS 定製的硬體，包含伺服器、網絡設備、電源等等；
不支持本地硬體運維管理。也就是機器有壞的，或者機器裡面的硬碟、CPU 等部件有問題，只能提申請整臺機器更換，不能本地開機維修、更換。每臺機器上插有專用的加密晶片，防止任何部件被更換或者單獨讀取數據。
不支持本地軟體和雲資源管理。AWS 公有雲上的 Outposts 服務是用戶管理本地雲資源的唯一入口，其他方式一律不支持。比如，每臺機器的SSH，或者帶外管理不對用戶開放，用戶也完全沒有辦法訪問；
不支持軟體定製。Outposts 運行的所有軟體，統一接受 AWS 軟體推送，不支持定製，比如，改個 instance type 啥的，肯定不行的，當然你可以向你的客戶經理提需求。
不支持離線部署和運行。必須至少 1 Gpbs 以上專線與 AWS 最近的 Region 互聯，從 AWS 公有雲 Console 中啟動和部署 Outposts。業務常規運行期間不能長時間中斷專線，這是強要求，在 re:Invent 真機演示現場與技術人員確認，如果與 AWS 公有雲的專線連接中斷超過 4 個小時，所有服務將不可用，業務會受影響。
傳統 IT 公司都能給你的，AWS 就不給！
看到這裡，有人開始失望了，友商也開始嘲笑了，這些都是客戶的核心需求啊，而我家的私有雲產品全都支持，我才是真正做到客戶至上，滿足客戶幾乎所有的需求。
閹割了客戶的「核心需求」，改變了二三十來年企業 IT 產品最基本的遊戲規則，AWS Outposts 到底能不能被市場接受？這款產品會是像 Amazon Fire Phone 一樣徹底的失敗 [4]，還是會像 AWS 一樣，成為亞馬遜下一個千億美金的產品？
AWS 為什麼要改變遊戲規則？
我們繼續來深挖一下，AWS 如果需要滿足以上需求，結果會怎麼樣？
如果以出售的方式，客戶會說，這是我的私有資產，行，那客戶就有責任對他的上線、運行、維修、下線、淘汰等硬體的完整使用周期負責，硬體裡的軟體也需要自行安裝和維護。那麼，AWS 需要把自己的私有軟硬體技術拆開然後封裝好，每一個產品有 2 大文檔體系，一個是面向最終用戶，像 AWS 公有雲上的文檔體系，另一個是面向 IT 管理員，還要一個一個地培訓客戶客戶，教客戶或服務商如何安裝、部署、維修，然後構建總代、經銷商、服務商等等一系列體系，用戶最終用上，面對這樣一個複雜的私有雲體系，用戶可能要再等 3 - 5 年之後了。
如果支持自帶硬體，雖然給予了客戶硬體採購的靈活選擇權，但用戶體驗的犧牲更大。因為，那 AWS 為了滿足客戶需求，會推出一個硬體兼容性清單，協調各大硬體產商，自研的 Nitro 硬體體系頓時失效，多年的硬體經驗立馬失效。AWS 開發軟體時，只能基於市場主流硬體的平均特性來設計軟體，無法利用硬體方面最新的創新。這是 OpenStack 等開源或商業私有雲軟體最痛苦的地方，只能在軟體上下功夫，還要滿足幾乎無限的硬體差異化需求，性能卻受限於硬體的平均性能。
如果支持用戶在本地管理軟硬體，那 AWS Support 的難度增加百千倍，這個時候 AWS 就得培訓現場工程師，或者建立私有雲硬體的分銷和服務支持體系。中間成本大幅增加，最後都由客戶來承擔這個成本。
如果把管理和控制平面放在本地，重複資源建設不說，會出現雙頭管理的問題。對資源的合理調度、如何判斷機器故障，等責任也會由用戶承擔。
如果支持軟體定製，那麼 AWS 就無法實現所有客戶一套代碼，AWS 全球的統一創新無法快速地應用到這裡來。定製越多，離主流越遠，必須內部維護無數個軟體版本，最後奔潰。
如果支持離線部署，AWS 的 TAM 們就必須長期在客戶現場駐場了。要麼用戶付出高額的成本，要麼沒有優秀的人才往你這用派駐。
每一個「需求」的滿足，背後都是無數原廠商、代理商、服務商的多年的噩夢。也是曾經所有開源的、商業的私有雲產品失敗的根本原因。
從系統可靠性角度來分析，以上 6 條核心的「不支持」，都直指一個事情：減少系統的輸入參數的變量個數，簡化系統設計，關注核心需求，提升系統安全和穩定性。
一套分布式軟體系統的內部狀態的管理就已經夠複雜了，再加上外部幾乎無限的多樣性的變量輸入，會讓系統存在大量不可知的狀態。比如，支持自帶硬體，世界上的硬體廠商雖然有一些共同遵守的標準，但這麼多年來，每家企業為了贏得市場競爭，都會特意做些差異化的功能，每一款硬體的差異化，對追求統一管理的分布式軟體來說，都是一個新的變量輸入，需要優雅地處理這些異常。更何況，還有很多差異化的硬體根本沒有見過，容易引入未知的變量，做過程序設計的人都知道，一旦一個系統處於不可知狀態，這個系統離奔潰就不遠了。
最關鍵的問題是，這真的是客戶的需求嗎？還是客戶 IT 部門的需求？亦或是客戶多年來被傳統 IT 公司培養的習慣性動作？
服務過百萬雲上企業客戶的 AWS 太懂客戶了，客戶真正想要的是，麻煩事別找我，我只想支持好業務應用和業務創新，這才是企業的核心價值。
亞馬遜 CTO Werner 大叔在 2017 年的 AWS re:Invent Keynote 中，就指出過未來企業數位化是一個什麼狀態：
圖：AWS 2017 re:Invent Keynote by Amazon CTO Werner Vogels
未來的企業只需要關注自己的核心業務邏輯（所有的代碼都將只是業務邏輯代碼），剩下的東西並不是公司的核心競爭力，則可以使用雲提供的共享服務，降低業務創新成本，提高業務迭代速度。
AWS 試圖告訴我們的真相是，AWS 真正服務的對象是企業的決策層、業務創新開發人員、數據分析師等等為企業創造核心價值的人員。而不是傳統 IT 市場所定義的 IT 人員。
在堅信誰是自己真正的客戶之後，AWS 拋開了傳統 IT 行業所有的歷史包袱，和慣性傳統，做出了歷史上最大膽的取捨，在此之前沒有哪家科技公司敢做得這麼徹底。
回到用戶，前面提到 AWS Outposts 的奇葩設定，也分析了 AWS 為什麼這麼做，那麼，站在客戶視角，客戶最終能獲得什麼，為什麼需要。
AWS Outposts 給客戶帶來什麼
而「犧牲」所有這些權限，就為了獲得一項體驗——與 AWS 公有雲一致的體驗。這可是私有雲發展的終極目標，AWS 第一次做私有雲，還是 v1 版本時就已經做到了。
這個說法好像曾經也有不少其他廠商的私有雲 / 混合雲產品這麼說過，來看看這個「一致的體驗」具體到了什麼程度。
AWS 有一個經典的網絡布局方式，即 Region / AZ 模式，可以實現數據中心級別的高可用，即時一個 AZ 出問題，部署了 Multi-AZ 模式的服務不會受到影響。也這成為了所有公有雲平臺的標配。客戶本地 Outposts 是以一個 AZ 的方式加入 AWS Region：
圖：AWS Outposts 接入 AWS 網絡之後變成一個 AZ
如上圖，一個 Region 的一個 VPC，可以即包含公有雲 AZ 上的 Subnet，也包含 Outposts 中的 Subnet，本地 Outposts 使用起來跟 AWS 的一個 AZ 沒有區別。
另外，有些控制層面的服務是運行在 Region 層面，尤其是涉及需要高可用的服務，比如VPC，EBS，S3，EKS等等服務的控制層面不屬於任何一個 AZ，而是在 Region 級別。這就意味著，這些 Region 級別的服務，本地 Outposts 不需要重複創建資源來承諾控制層面的負載，直接利用公有雲的控制平臺即可，比如 ECS 服務：
圖：ECS 的管理控制平臺在 AWS Region [3]
注意到， ECS 的控制平臺是在 AWS Region 中的，而具體的ECS Cluster，則是在 AWS 或 Outposts 中的 AZ。也就是說，你不需要為 ECS 控制節點付費，即可享受 ECS 服務。還有一眾的管理和編排類的服務都有類似的特點，如：AWS CloudFormation, Amazon CloudWatch, AWS CloudTrail, Elastic BeanStalk, Cloud 9 等等。
這種級別的「一致性體驗」，是以前任何私有雲/混合雲產品形態中，從來沒有過的創新。
更多的，訂購了 Outposts 的客戶，你還將獲得：
AWS 過去及未來雲服務所有創新，AWS 的創新能力有目共睹，只要本地 Outposts 有條件承載，都會推動到你自己數據中心的 Outposts 中來。比如有合適的新服務、新功能時會自動給推送，這一點與 Tesla 電動汽車的 OTA 更新機制類似。比 Tesla 更極致的是，Outposts 硬體有升級換代時，也會免費上門更換。事實上，從 2018 年到今天，我們能看到 Outposts 上支持的服務也越來越多；
極高的可靠性和穩定性。本地 Outposts 的 SLA 是與公有雲的 AZ 一致的。
徹底的免運維。你本地不用顧任何人專門照顧 Outposts 環境，根據文檔，客戶本地只要保證網絡是通的，電源是開的，其他一切都不用管。AWS 全球統一運維和服務團隊，加上 AWS 多年來的自動化監控和運維工具，7/24 小時實時保駕護航；
0 等待交付。完全不需要漫長的傳統企業項目的流程，什麼需求分析、 PoC等環節通通不用。下單機器到貨後，當天即可投入生產。本地只要準備好空間、電源和網絡環境即可。經確認，如果服務到期用戶取消訂單，AWS 會上門把設備拖走。完全不用擔心設備利舊、報廢處理等問題。
上百萬企業拋棄自己的數據中心，把業務全部遷移到公有雲。公有雲能夠做到，忽略我的存在，只需要關注你的業務邏輯。那為什麼不直接上公有雲呢？什麼情況下需要本地部署 AWS Outposts?
Outposts 解決哪些市場需求
是的，大部分情況下直接使用公有雲就能很好解決業務問題，AWS Outposts 主要設計滿足以下需求：
極低延遲的本地化計算和存儲需求。有很多場景，比如，醫療圖像處理、工業設備控制、運營商 NFV 等邊緣計算的需求，5G 出來之後運營商類似需求會大爆發；
把計算能力搬到離海量數據更近的地方。本地短時間產出海量數據需要處理，而這些數據大太無法有效地傳到公有雲上處理，比如電視臺、工廠等場景。
Outposts 不能用來解決以下需求：
因為對公有雲不信任，而使用私有雲的需求。因為 AWS Outposts 使用的安全是基於與公有雲一致的安全體系，如果無法信任公有雲的安全體系，也無法接受私有雲的安全。AWS 從不會做沒有業務價值而投其所好的事情，比如，為了讓你感到安全，通過把物理設備在你家裡，讓你能夠親眼看到，親手摸到，讓你獲得一種虛幻控制感，而是希望你能從客觀的安全體系和技術原理來自己判斷是否安全；
想通過買一個私有雲，希望從硬體到軟體自己也能學會，進而達到「自主可控」的需求。AWS 堅持把實現的所有細節以技術文檔、白皮書、博客、re:Invent視頻等方式向公共開放，直接去學習這些材料，自己來開發和設計，可能更直接、效率更高。
理解了 Outposts，這次 re:Invent 發現另外 2 個逆天的服務就可以很好理解了，分別是 AWS Local Zones 和 AWS Wavelength。
AWS Local Zones 的背景是，AWS Region 雖然分布全球，但一個國家或地區只有 1 個 Region，中國有北京和寧夏 2 個 Region，已經是除美國之外 Region 最多的了。因為 AWS 建設一個 Region 的標準和成本相當高，但有了 Outposts 之後，可以很快組建一個 Outposts 集群，形成一個區域性、小規模的 AWS Zone，覆蓋一個城市或一個省的需求。
圖：AWS 2019 re:Invent Keynote by AWS CEO Andy Jessy
AWS Wavelength 則是專門為運營商設計的，大致對應在 ICT 圈已經講了多少的 NFV 邊緣計算概念，國內大致基於 OpenStack 做了比較多年，到目前為止，還沒有一個廣泛被採納的方案，基本上都處於高度定製化階段，而這次 AWS 給出的是一個高度產品化的方案，當然不用猜測都知道，也是基於 Outposts 構建的解決方案。如 Verison 在這次 re:Invent 上列舉的如下需求：
圖：AWS 2019 re:Invent Keynote by Verizon CEO Hans Vestberg
當我看到基於 Outposts 的 Local Zones 和 Wavelength 發布時，我就知道，Outposts 模式已經被證明是成功的了。AWS 自己已經先開始找場景大規模用起來了。
這三者什麼關係：
AWS Region —— 全球及國家範圍內提供服務，同時提供國家間、洲際的骨幹網絡
AWS Local Zones —— 市級或省級範圍內提供服務
AWS Wavelength —— 行動網路接入範圍內提供服務
AWS Outposts —— 你自己的數據中心範圍內提供服務
所有的節點都是互相強連接的，這是一張巨大的網絡，像人體的血管網絡一樣，即有主動脈，又有毛細血管，AWS 把自己及其合作夥伴的最新科技創新通過這個網絡輸送到各行各業。
AWS Outposts 給世界帶來的意義和啟發
我們很幸運，親眼見證了自己熟悉的行業面臨的巨變，AWS 通過一款產品有可能改變私有雲市場 10 多年的混亂與低效。
其意義不亞於 iPhone 對於手機行業重塑與規整，iPhone 拋棄實體鍵盤和觸控筆，和 Outposts 拋棄私有雲的離線模式，有異曲同工之妙，都是通過一個小小的杆槓撬動了一個行業巨大的改變。
特斯拉通過電動汽車正在優化 100 多年未曾變化的汽車市場，特斯拉通過 OTA 讓汽車變成一輛活的，可以演變升級的汽車。Outposts 也通過統一私有雲控制平面、統一推送更新升級，也有著相似之處。
偉大的創新都經歷了開頭被無數人鄙視，然後繼續堅持改進默默地改變世界。
Outposts 這個案例非常值得中國 2B 企業服務市場的從業人員思考，不管是創業者還是高管。
按照博弈論的理論，中國 2B 企業服務市場是一個典型的囚徒困境，即通過多次博弈共同選擇導致了一個多方共同利益受損的局面。
我們可以看到，一方面，在企業服務市場上太多的乙方們苦得一逼，另一方面甲方也過得很不舒服，甲方長期以來也找不到合適的供應商，反正就將就著，湊合湊合就行，苦一點累一點。有實力的公司經常還找不到合適服務提供商，最後迫不得已，乾脆逃離社會協作分工網絡，紛紛選擇投入巨資進入非主營、非核心業務，比如，做自己做私有雲，行業雲等 IT 基礎平臺，或者開始自研各種中臺。導致整體社會創新成本居高不下。
只有通過有實力公司的創新改變遊戲規則，才能最終打破這個囚徒困境，減少博弈多方的無效損耗，實現社會利益最大化。在 re:Invent 上見過很多的歐美專業服務類公司，同樣是當乙方，同樣是賣服務，哪怕是自由職業者，都能生活得很體面、有尊嚴，而國內同行們大多活得「苦大仇深」的樣子。
AWS Outposts 的出現有助於打破國內私有雲，甚至更廣義的 2B 企業服務類市場囚徒困境這個局面。只希望 Outposts 早日突破障礙，進入中國市場。
參考資料：
https://d1.awsstatic.com/re19/AWS19-0029%20Outpost%20Solution%20Brief_v7%20Final.pdf
https://aws.amazon.com/outposts/
https://www.youtube.com/watch?v=n7AWdZVCq7g
https://36kr.com/p/218602