本文是原創，首發於微信公衆號『 Moehoo猛虎 』
【導讀】OpenStack落地德國大衆，始於銳意創新的雄心壯志，失於孤注一擲的執拗，終於一意孤行後的平淡結局。
2016年4月，“純OpenStack廠商”（the Pure-Play OpenStack company）Mirantis宣佈：他們戰勝了強大的紅帽（Red Hat）公司，得到了德國大衆汽車集團（Volkswagen Group，以下簡稱爲“德國大衆”）的OpenStack系統集成服務大單。
實際上，Mirantis早就在爲德國大衆做OpenStack的技術實施和部署工作了，就在宣佈這個消息時，德國大衆位於Wolfsburg（沃爾夫斯堡，其總部所在地）的新數據中心已經上線運行了，正是Mirantis的技術人員完成了所有的OpenStack集中式部署。
至少在表面上，德國大衆決絕地拋棄了以VMWare爲代表的閉源商業雲平臺技術方案，轉而採用開源的OpenStack構建其私有云，爲OpenStack落地大型跨國集團公司又增添了一個新案例。毫無疑問，對Mirantis而言，這是一次巨大的勝利，而整個OpenStack開源社區也爲此而振臂歡呼。
然而，德國大衆的IT管理部門Group IT有約1萬員工，維護着700多個正在運行的應用系統，在全球有超過兩百多萬的各類日常用戶，包括：61萬德國大衆的員工，33萬代理商用戶，4萬多家各類供應商的員工，還有數以百萬計的普通用戶每天都在訪問系統以查詢產品信息。
龐大的用戶羣，還有那些基於KVM開源免費軟件和VMWare等閉源商業軟件而構建的雲計算環境，再加上歷史上爲數不少的基於RISC架構服務器的傳統應用，恰如一隻行進中的龐大艦隊，想要阻攔如此沉重而巨大的慣性，需要付出怎樣的代價？
關心雲計算技術趨勢的人們更是不禁要問：德國大衆真的要把現有的IT基礎設施都遷移到OpenStack環境中嗎？基於OpenStack重新構建其所有IT基礎設施竟然會如此輕而易舉？
人們開始爲德國大衆而擔心：難道真的要把所有雞蛋都放在一個籃子裏？這究竟是銳意創新還是孤注一擲？
德國大衆曾多次將其應用OpenStack的歷程稱爲“大衆集團的OpenStack之旅”（the OpenStack Journey of the Volkswagen Group）。事實上，如果想要得到以上問題的答案，也必然要追溯此“大衆集團的OpenStack之旅”的歷程細節。
轉向OpenStack開源雲平臺的緣由
德國大衆是典型的大型製造業企業，管理模式極爲複雜，旗下有12款汽車品牌。
德國大衆的研發、生產、製造、銷售和服務機構遍佈全球，快速發展的全球化業務變得越來越複雜，大幅度橫跨地理空間的業務模式更相應地導致了IT管理的高度複雜性。相應地，IT技術服務必須要與這種複雜性相適應並進而成爲其業務發展的驅動力。
顯然，一個有效的解決之道是建立一個整合性的基礎設施架構管理平臺，而云計算平臺與生俱來的特性天然與此相契合。
2016年4月，OpenStack峯會在奧斯汀舉行，德國大衆的IT基礎設施負責人馬里奧•穆勒（Mario Müller）在宣講時，引用天才計算機大師阿倫凱（Alan Kay）的名言“預測未來的最好辦法就是創造未來”（The best way to predict the future is to invent it），據此，進而提出了其IT基礎架構的治理理念：重建IT基礎架構”（Reinvention of the IT Infrastructure），這就清楚地解釋了德國大衆選擇OpenStack的思想基礎：重建（Reinvention）。
重建IT基礎架構，是爲了日常工作流程的極大改進，也是爲了管理高複雜性的IT架構，更重要的是，能夠加速將IT基礎設施交付給業務應用的能力，降低生產成本並促進IT治理的標準化。一言蔽之，以IT技術的巨大變革驅動德國大衆的全方位轉型。
更加具體而確切地說，爲了加快驅動創新型業務的發展，Group IT需要將提供平臺資源的時間從以月計降低到以小時計，這就需要重建德國大衆的IT基礎設施並將之轉爲私有云。
Group IT也對閉源商業雲平臺解決方案進行了評估，但最後還是認爲開源雲平臺能夠以其快速的創新週期而迅速地整合新技術，而OpenStack是領先的開源私有云平臺，基礎架構團隊很自然地對之進行了重點而深入的技術調研和評估，掌握了其具有極強的技術功能和缺乏商業的技術支持等情況。在經過漫長的討論研究後，德國大衆最終確定了基於OpenStack構建其私有云的技術路線。
爭奪德國大衆的對決
爲了能全方位地開始“OpenStack之旅”，獲得商業公司的強大技術支持是最基本的必要前提，因此，審慎地挑選OpenStack的發行版本及其系統集成服務商就成爲重中之重。
由此，在經過德國大衆一系列的比較和挑選之後，Mirantis和Red Hat成爲了最終的對決者。
基於64個具體的使用場景，德國大衆給出了相應的技術任務。兩家公司精華盡出，人馬駐紮在德國大衆總部，在兩週的時間內，各自給出瞭解決方案並予以實現，然後，再用一週的時間向德國大衆展示成果。
最後的勝出者是Mirantis，他們的說法是：經過一系列全面而嚴格的篩選流程，Mirantis的60多名專業技術人員以98%的執行率戰勝了Red Hat的同行，證明了Mirantis OpenStack版本的穩定和技術人員快速部署的能力，取得了這場來之不易的勝利。
Red Hat在黯然離去後，起初對結果不置一詞，在媒體的追問下，終以電子郵件作了一個高姿態迴應：“總的說來，我們期待電信行業、企業和政府選擇基於OpenStack構建私有云基礎設施。這是一個巨型市場，根據研究機構451 Research的預測，OpenStack可能會在2017年達到25億美元的規模。所以，我們歡迎並需要一個健康的OpenStack市場生態系統。”
這是一個意味深長的迴應，令人遐想聯翩。
反目：Mirantis與Red Hat
其實，Red Hat和Mirantis曾經是密切的合作關係，Mirantis的A輪融資，就是由Red Hat領投了1000萬美元。
那時候，Mirantis還只是專業部署OpenStack的系統集成商，而RedHat則有雙重身份，一個是企業級Linux的領袖，另一個是OpenStack供應商。顯然，那時候兩者之間是典型的合作雙贏關係。
但是，隨着Mirantis轉型成爲OpenStack供應商，這樣一種合作雙贏的關係也就不復存在了，雙方開始矛盾不斷。最後，在Red Hat於2014年收購法國的OpenStack雲計算領導廠商eNovance之後，就徹底地消失於Mirantis的股東名單中了。從此，兩個曾經的合作伙伴分道揚鑣，成了競爭對手，雙方摩擦不斷，以至於Red Hat甚至放話“不支持在Mirantis OpenStack上的RHEL”。就這樣，從暗流涌動的無聲較量開始，逐步地發展到了針尖對麥芒的正面交鋒，終於，在德國大衆的OpenStack系統集成大單上兵戎相見，殘酷廝殺之後，流血漂櫓。
質疑與追問
一個成熟企業在IT基礎設施架構等重大問題上的通行思路是：基於對企業當前現狀的全面和客觀的認識，立足於“共生、共存、共榮”的原則，本着謹慎的態度對OpenStack等開源雲平臺技術進行測試、試用、推廣、擴展和最終推行。
因此，在人們爲德國大衆Group IT領導人擁抱開源新技術的勇氣而喝彩的同時，在內心徘徊不去的卻是深深的疑慮：OpenStack因快速的創新週期而能迅速整合新技術，但其體系架構也因之而處於極度活躍和激烈動盪的變化之中。誠然，將OpenStack納入企業的IT基礎設施架構之中，逐步地進行推廣，必將給企業業務帶來創新驅動力，然而，想要進而用OpenStack一統江山，對將“成熟、穩定、高效”運行放在首位的企業而言，則是需要決策團隊頭腦清醒地予以全面和審慎思考的。
既然有如此巨大的風險，爲什麼德國大衆的Group IT還堅持作出如此執拗的決定？
不僅如此，令人詫異的是，德國大衆竟然拒絕了擁有雙重身份（企業級Linux領袖和OpenStack提供商）的Red Hat。人們詫異於此，並非由於Red Hat是一家大公司，而是緣於一個共識：技術實力和服務能力纔是選擇廠商是最根本的考量。衆所周知，在各類IT項目中，如果實施方擁有自主的核心技術，就能極大地促進項目進展。
而Red Hat正是開源KVM項目的所有者（Red Hat於2008年收購了KVM項目的原創公司）。
KVM全稱爲Kernel-based Virtual Machine，即Linux內核級的虛擬化。2007年1月，KVM被納入到Linux系統的內核中，在開源虛擬化上，近年來KVM異軍突起，取代了XEN而成了事實上的標準。
事實上，德國大衆於2015年初就開始推行的服務器虛擬化正是基於KVM技術，而且，在任何版本的OpenStack底層，都是KVM技術。在這樣的背景下，德國大衆仍然放棄了來自技術源頭的強力支持，這又該作何理解？
儘管Mirantis聲稱自己是經過全面而嚴格的篩選流程後勝出，但Red Hat可不這麼想，“一個健康的OpenStack市場生態系統”，這其中又有幾許暗示和多少不甘？
德國大衆完全無視Red Hat“不支持在Mirantis OpenStack上的RHEL”，這是否意味着今後在Mirantis OpenStack環境中不再使用RedHat的企業級產品RHEL？爲了屬意於Mirantis，竟然付出與掌握自主核心技術的Red Hat失和的巨大代價，又是否值得？
要尋求這些問題的答案，唯一的途徑就是：研究德國大衆OpenStack雲平臺的實際落地情況，從中分析其實際的技術執行思路和方向。
構建雲計算平臺的歷程
下圖是德國大衆構建雲計算平臺的歷程，其中清晰地展示了其構建雲計算平臺的各個歷程和細節。
2015年初，德國大衆着手IaaS平臺構建的第1步：在基於X86架構服務器的Linux服務器上，採用KVM技術推行服務器虛擬化。到2015年第2季度結束時，完成了這一階段的工作，這爲後續的IaaS平臺構建奠定了良好的技術基礎，積累了技術經驗。
隨即，自2015年7月始，推行第2步進程：基於OpenStack，開始進行IaaS平臺技術路線的論證和確定，立足於此，進行挑選和定奪OpenStack供應商和系統集成商等工作，Mirantis最終勝出。2015年10月，Mirantis進駐德國大衆總部，開始系統性地部署Mirantis OpenStack，此項工作於2015年12月完成後，IaaS平臺初步建成，Cloud IT雲正式上線運行。隨後，有兩項工作平行地展開：其一，在其總部所在地，啓用總面積爲2000平方米的新數據中心，對已經初步建成的IaaS平臺進行橫向擴展，此項工作於2016年4月完成，交付物是新數據中心的上線運行；其二是執行雲平臺構建的第3步進程，即：基於開源軟件CloudFoundry進行PaaS平臺的構建。此項工作於2016年6月完成後，PaaS平臺正式上線運行。
從2016年第3季度開始，開始第4步工作，即全面推廣，推廣至亞太地區和非洲地區，同時，展開構建混合雲的工作。
立足於德國大衆總部的新數據中心，在1年半的時間內，順利完成了基於OpenStack的雲平臺構建的基本建設任務。整個過程漸進演變，步步爲營：先推行服務器虛擬化，再試水IaaS平臺，成功後即進行橫向擴展，接着，立足於Iaas平臺，搭建PaaS平臺，最後，立足於既有的經驗，將雲平臺擴展到全公司範圍。沒有絲毫激進的跡象，人們只看見大型企業構建基於OpenStack的雲平臺的普遍做法和通用歷程。
而且，如果真如Coud IT所聲稱的那樣，要用OpenStack去“Reinvention”其IT基礎設施架構，那麼，對基於閉源商業雲平臺技術（以VMWare爲代表）所構建的生產環境，將之遷移到OpenStack環境是必要的工作，可是，在1年半的建設過程中，德國大衆並沒有進行此項工作，只是集中力量在循規蹈矩地建設基於OpenStack的雲平臺。
IT交付模式
德國大衆的IT交付模式如下圖所示。可以看到，傳統的各類應用、基於開源KVM的服務器虛擬化的典型應用，新的基於OpenStack所構建IaaS平臺的“雲就緒”應用，都在其中留有被接受的既定模式。
德國大衆的技術人員在2016年10月的OpenStack峯會上透露：德國大衆目前還是典型的異構型IT基礎設施架構，“我們是什麼硬件和操作系統都有。”因此，在這樣的現實背景下，德國大衆的IT交付模式必然呈現出長期的多樣性。
第一種IT交付模式有兩種表現形式：
一些傳統應用（比如，大型製造業企業的生產實時系統）是基於RISC架構的小型機，在這些傳統應用上運維着極其重要的數據。這些應用具有極強的專用性，大都無法被改造爲適應於雲計算環境的新型應用，但是，這些應用及其數據又必須能夠爲典型應用和“雲就緒應用”所訪問。
基於X86架構服務器上的Linux系統，採用KVM進行服務器虛擬化，以此構建了德國大衆的標準應用平臺。基於此平臺，一些應用已經不再在小型機系統上開發和部署，而是部署於此平臺之上，“這是一個巨大的進步。”德國大衆的技術人員在峯會上說。
第二種交付模式就是“雲就緒應用”（Cloud Ready Applications）。在這方面，德國大衆確實有幾個成功的案例：
客戶服務部門的大數據應用經常產生起伏不定的工作負載，舊應用平臺無法適應這種變化。2015年，在Group IT雲於12月上線運行前，基於OpenStack平臺提供的彈性計算特性，客戶服務部重寫了這個應用，取得了很好的效果。
已經或正在被改造爲“雲就緒”的應用還有：新一代的客戶網站、汽車配置工具(Car Configuratior)、WeDrive汽車共享應用、智能產品分析、3D渲染等。
然而，必須注意到，即便在德國大衆“雲優先”（Cloud First）的IT策略下，大部分應用仍然運行在其既有平臺之上。逐個改造既有的傳統應用是不切實際的，應當尋求一種系統性的技術機制，使得既有應用和新型“雲就緒”應用共同生長，相互適應並協調運作，最終，構建出一種良性的基於雲計算平臺的IT生態環境。令人不解的是，德國大衆在這方面沒有進行任何實質性的推進。
OpenStack基礎設施架構
下圖是德國大衆的OpenStack基礎設施架構，從中可以探知其建設思路和願景是：應用大規模自動化的集羣部署技術，逐步推行基於OpenStack的基礎設施架構，覆蓋主要的設計開發、生產和質量保證等重要環節，將雲計算平臺應用於驅動企業的業務創新力。
數據說明問題，比較能夠揭示發展趨勢，追溯德國大衆OpenStack雲平臺中的計算資源的演變歷程，有助於作出進一步的結論。
2015年12月，在Group IT雲初步建成時，OpenStack雲平臺中的計算資源爲：80臺物理服務器（約1920個CPU Core）、約57,000GB內存、約100TB存儲（三副本，實際可用約爲33TB）
2016年5月，OpenStack雲平臺已經在其旗下的所有12個汽車品牌和若干部門投入試用，共有約248個租戶（約700餘人）在使用這些資源。其時，位於沃爾夫斯堡的新數據中心已經上線運行，在其OpenStack雲平臺中，計算資源爲：150臺物理服務器（約3,600個CPU Core）、約110,000GB內存、約840TB存儲（三副本，實際可用約爲270TB）。
2016年12月，OpenStack雲平臺中的計算資源增長爲：約210臺物理服務器（約5,000個CPU Core）、約150,000GB內存、約1,800TB存儲（三副本，實際約爲600TB）。
預計到2017年12月，OpenStack雲平臺中的計算資源將會迅猛地增長至：約370臺物理服務器（約9,000個CPU Core）、約260,000GB內存、約7,500TB（三副本，實際約爲2,500TB）。
以上的數據充分說明，從2015年初啓動“OpenStack之旅”開始，到2016年12月底爲止，在兩年的時間裏，德國大衆的OpenStack雲平臺的發展坡度較爲和緩平穩，也取得了一定的進展。然而，在2017年，Group IT將致力於急劇擴大OpenStack雲平臺的覆蓋範圍，將基於Mirantis OpenStack的私有云擴展到亞太地區和非洲地區。
不僅如此，德國大衆還計劃將私有云與公有云整合在一起形成混合雲，籍於此，進而將網聯汽車和無人駕駛的技術從實驗室推向市場。
在很大程度上，德國大衆的OpenStack雲平臺是處於獨自發展的狀態，尚無法有效地與既有的IT基礎設施相融合，也無有效的手段對其進行管理，即便是在局部（即，沃爾夫斯堡的新數據中心），OpenStack也遠未形成完整有效的統一IT基礎設施架構。在這樣的情況下，德國大衆貿然在2017年激進地推廣OpenStack，只能愈加拉大OpenStack與既有IT基礎設施之間的裂縫。
雲計算平臺的邏輯架構
以下的圖表描述了德國大衆雲平臺的邏輯架構。可以看到，邏輯架構分爲Undercloud和Overcloud兩部分，清晰明瞭，對各雲平臺組件的選擇亦得當，若能在生產環境中基本予以實現並應用，則毫無疑問是一個成熟的雲平臺。
而實際情況卻遠非如此，空中樓閣似的規劃並沒有落地。德國大衆甚至沒有意識到，由於OpenStack與生俱來的技術特性，決定了其根本無力獨自承擔構建、融合和管理複雜的企業IT基礎設施架構的重任。
別求新聲於異邦
2015年9月，美國環境保護署(EPA)發現：德國大衆在所產車內安裝非法軟件，以規避美國汽車尾氣排放規定。“檢測門”事件事發，世人爲之驚愕。
如果說，“檢測門”的錯誤是由於失去自我約束的道德迷失，那麼，重建IT基礎設施架構的失策則是源於想要自我完善的急於求成。
OpenStack落地德國大衆，這“OpenStack之旅”，始於銳意創新的雄心壯志，失於孤注一擲的執拗，終於一意孤行後的平淡結局。
企圖拋棄既有的IT基礎設施，一味地倚重於OpenStack以求重建IT基礎設施架構，在整體建設思路上，德國大衆Group IT犯了方向性的錯誤；
拒絕開源KVM技術發軔源頭的廠商Red Hat，德國大衆Group IT的洞察力和掌控力導致了稍遜一籌的技術細節實現。
德國大衆平淡無奇的“OpenStack之旅”，再次證明了一條已成爲業界共識的金規則：OpenStack，這個偉大的雲計算未成品，它與既有IT基礎設施架構之間的關係是“共生、共存、共榮”。要想構建一個全面統一的雲計算管理平臺，只能“別求新聲於異邦”，引入成熟的雲管理平臺（CMP，Cloud Management Platform）。唯其如此，風起時，“雲”才涌動如潮。
