技術頭條：乾貨、簡潔、多維全面。更多雲計算精華知識盡在眼前，get要點、solve難題，統統不在話下！
在接受不同採訪時我經常會被問到這麼一個問題：OpenStack到底發生了什麼？就像人們認為OpenStack已經死了一樣。而每次面對這個問題，我都會在回答之前做出害羞無辜的表情。這裡我要給大家一個提示：OpenStack並沒有死，只是經歷了風雨。
這個項目目前運作仍十分健康，依舊遵循發展曲線推進：OpenStack發展至今已足夠成熟，這一點已經不足以引起人們的興趣來引發討論了，所以大家隨之在想OpenStack是不是發生了什麼，這種情況是可以理解的。
問我這個問題的人通常好奇又善意，我認為我的回答跟我的專業背景有很大的關係，所以即使是在採訪時，我會偏向於採用閒聊的方式。我決定今天重新討論這個話題。下次要是再有人問同樣問題，我就會讓他來讀一讀這篇文章。
要知道，為了實現生態系統長期持久的成功，我們需要一個超規模的OpenStack公有云，還需要在我們已有的Iaas/Paas層上構建一套健康的SaaS應用程序，除此之外，我們還需要在多個hyperscale來避免引力問題（在早期，這就是RackSpace）。
很多人都在公開場合談論到的一點是，常見的頭條新聞將OpenStack與AWS進行比較，每個風險投資機構和分析師都想知道OpenStack是否已經為企業提供服務做好了準備。我甚至還曾在一個小組討論裡探討過這個問題！（網上有鏈接記錄，但我不會在這裡分享，因為我不想回憶當年自己的形象）但隨著時間的推移，我們成功的關鍵部分從未實現。為什麼會這樣呢？
早在2014年時，我在惠普雲工作，那時候資金正源源不斷地流入OpenStack，我們也正為此得意洋洋，那是OpenStack發展達到頂峰的一年，巴黎峰會上嘉年華的場景對於現在的我來說依然記憶猶新。這一現象實則出於電信公司和硬件供應商試圖影響OpenStack方向的原因，但對於局外人卻是霧裡看花。更具體地來說，這些公司希望為他們能夠迅速上市的集成私有云解決方案創造技術基礎。
而在私底下，我們可以看到，這些市場勢力與hyperscale實際實現是背道而馳的。大帳篷項目（The Big Tent）是一個試圖解決當中一些問題的大膽之舉。我們（即技術委員會）使勁自己最大的力氣，但最終還是無法解決這些問題，因為錢包控制權並不掌握在我們手中。
正如大家所看到的，當時幾乎所有為OpenStack做出重大貢獻的公司都依賴於企業客戶，這其實是業內知名公司每年花費巨資在彼此合作的公司之上的另一種較為好聽的說法。與hyper-scalers不同，企業客戶通常對構建自己的服務器或編寫自己的交換機固件並不感興趣，他們會選擇從這些產品服務提供商那裡購買（以及給他們的支持合同），並且希望繼續從這些交易中賺錢。
與此同時，發行商和運營商正努力實現OpenStack可安裝，以便能夠展開和維護部署來滿足市場需求。而且企業對新的私有云領域的需求非常高。OpenStack開發團隊面臨（來自於發行商、電信公司、硬件供應商）巨大的內部壓力，他們要在具有地理彈性的少部分地區大約的1000-10000個核心中創建企業客戶所需並運行良好的軟件。
但是，為10000個和為10000000個核心構建分佈式系統存在根本性的差異。除了要改變代碼之外，增加三個數量級還需要對任何業務的運行方式進行根本性的改變。利潤率會越來越小。第三方支持合同、B2B交易、增值軟件這些被視為銷售團隊“車輪的潤滑油”已經不復存在了。企業硬件和軟件巨頭不願意重組那麼多業務，而像OVH這樣的公司其自然增長速度太慢了，儘管我認為他們仍然走在正確的軌道上。
創建一個可行的、開源的、超大規模的雲軟件解決方案與對OpenStack開發投資最多的公司的最大利益。
有一天，我以我一貫的方式試圖在餐巾紙畫出以下的圖。原來的版本已經遺失很久了，所以我把它從下面的記憶中重新畫出來。
影響來自錯誤的方向。電信公司、硬件供應商和發行商的產品管理（如ATT、思科、戴爾和紅帽等）投入大量資金來施加影響力、僱傭程序員編寫代碼、為奢華派對提供資金並推高工資水平（毫不掩飾地說，我確實很喜歡這些派對活動，同時我的薪酬待遇也很好）。與此同時，運營商越來越落後於發佈進程，幾乎沒有發聲（畢竟他們正忙著雲的運行），雲的最終用戶（應用程序開發人員）也幾乎沒有發聲。
到最後，營收需要從雲端上受支持業務的增長（即APP程序開發人員的成功）中獲得，但我們卻沒能實現這個目標，因為運營商無法充分擴大規模，或無法保持和維護一個健康市場在雲端上蓬勃發展所需的跨雲兼容性。圖表左側的每個人都忙於尋找自己的差異性優勢，從而無法促成彼此間的交易。
在這個情況下，作為可以看到問題所在的上游技術團隊領導正向我們每個公司內部進行遊說，希望能夠改變優先事項。我們說服了一些管理者和執行者在代碼和基礎設施方面進行戰術投資，但我們無法獲得足夠的支持來應對所需的更大變化。
只要金融影響者專注於中型客戶（MSP和企業市場）的商業模式，對於讓OpenStack在超大規模市場上具有競爭力所需的大量戰略方面，他們並無投資意願。因此，絕大多數開發人員在面對自己所屬的項目目標由項目經理和他們僱主內部的管理人員決定時，都忙於將一切為利用“增值集成”所設計的特性（也就是企業銷售週期中的潤滑油）驅動到代碼庫中，沒有人能夠解決對於正忙於擴大雲規模的部署人員來說很明顯的核心問題。
成功的hyperscalers已經消除了中間件的邊際成本。谷歌、AWS，甚至Facebook都在製造自己的服務器、交換機、存儲設備等。他們提供開源項目，然後付錢給開發人員進行維護和私有云版本的改進，這樣他們就可以保持領先，而一些項目現在正嘗試阻止這一趨勢。這些公司通過削減基礎設施的成本來擴大規模，但這些效率驅動舉措並沒能讓它們回到企業級市場中。他們在很大程度上成為了如今的巨頭，通過構建流程、打造團隊和搭建硬件來打破對第三方軟件和硬件的依賴和支持。
所以你可以看到，創建一個可行的、開放源碼的、超大規模的雲軟件解決方案是違背了對OpenStack開發投資最多的公司的最大利益的。
當你在看其他雲產品的時候，思考下當下可能會對你最喜愛的代言人產生影響的的相似利益衝突（Kubernetes，我正在看著你呢）
對於我們中那些早早加入OpenStack並夢想成為大人物的人，我想說：好吧，我們沒有機會在OpenStack中構建這些夢想了。OpenStack已經變成一種沒有夢想光環但或許更實用的可擴展工具，用於中等規模的基礎設施自動化，助力世界各地數千家企業，這包括許多非營利性和公益性機構。
而且，我想闡明的是，我很高興能夠通過採用我的方式幫助構建成了一個被廣泛使用的工具。
我現在發表這篇文章，是希望它能對所有在Kubernetes.投資的人起到警示作用。你將永遠無法像GKE那樣以同樣的規模並有效地運行它——除非你也一樣在組織全面變革方面進行投資。
即便如此，如果你使用Kubernetes，你可能也不會成功，因為讓其他人真正與GKE競爭是與谷歌的最大利益相悖的。
也許這也沒關係。事實上，OpenStack+Kubernetes是對於你正在構建的合適的模式，而且這兩個項目也不會在短期內實現無處不在的模式。
如果另一家公司想在hyperscale的空間中立於不敗之地，它需要從整體上審視自身的業務機構，並重復Google/Facebook/Amazon的開放源代碼私有化模式，把資金投資在自己的服務器製造中，或者與其他垂直聚焦的開放源代碼企業聯合才得以在市場上與對手競爭。
本文轉自CSDN雲計算
閱讀更多 啟迪雲Tuscloud 的文章
