全文包括三部分：
在本系列的第一部分，我介紹了企業級 OpenStack 的六大需求。現在，我會着重闡述接下來的兩個主要需求：開放架構和混合雲兼容性。讓我們馬上開始吧。
需求3 - 開放架構和減少廠商鎖定
我們已經討論過構造健壯的雲控制平面和雲管理系統。OpenStack 吸引人的特點之一是通過使用開源代碼平台來消除廠商鎖定。
“無廠商鎖定”是蛇油推銷技巧（Snake Oil Salesmanship）
你是不是被承諾過 OpenStack 可以避免廠商鎖定？完全沒有廠商鎖定只是個不切實際的想法 - 就是那種可以想象得很完美但是永遠不會實現的東西。任何系統，都有某種形式的廠商鎖定。比如說，你們部分人都應該用過 RedHat 企業版本的 Linux 系統，一個完全 100% 開源 Linux 的操作系統，來作為你企業的默認 Linux 版本。你看，RedHat 就是一種形式的鎖定。RedHat 的 Linux 是為了一個特定目標而設計的特定版本的 Linux。使用它，你就會被鎖定進它們的特定的參考架構、打包系統、安裝/系統引導等等，即使它是開源的。
實際上，在許多客戶那里，我沒怎么看到對鎖定的擔心，而更多的是對“更多鎖定”的擔心。打個比方，一個客戶，他要求保持匿名，基於廠商鎖定的考慮，對采用我們的塊存儲組件有意見，即使它是 100% 開源的。進一步了解后，我發現其實是客戶想繼續使用他們現有的存儲提供商（NetApp 和 Hitachi Data Systems）而並不想再去培訓他們的 IT 團隊再去使用一個新的存儲系統。可以看出來，他們對廠商鎖定的擔心，主要是不想有更多的鎖定，而不是完全想要消除鎖定。
因此，更重要的是，去了解你的企業所能承擔的風險。轉為使用 OpenStack, 就像前面 Linux 的例子一樣，意味着你通過針對新的軟件培訓你的IT團隊，以及可以從多個廠商去獲取開源軟件的支持，去減少某種風險。
換句話講，OpenStack 肯定可以減少廠商鎖定，但是不是徹底消除它。因此，去尋求一個開放的架構，然后期望收獲一個企業級產品吧。
鎖定一直存在，特別是使用企業產品
我希望鎖定不存在，但是它確實一直存在，就像你從上文中所讀到的那樣。這意味着，與其一味去尋求沒有鎖定，不如去看看你能接受什么樣的鎖定。一個企業級的OpenStack 版本，會通過一個開放的架構來提供一系列的選項。然而，一個真正的雲操作系統和企業產品，不會提供無限的選項。為什么不能呢？因為那樣的話其支持模型是不可持續的，各個產品提供商最終都會離開這個領域。即使是大型的廠商，也不會向所有用戶提供所有的選項。
如果你想圍繞 OpenStack 打造你自己的定制的雲操作系統，你可以盡管去做，但是那不是一個產品。它需要定制化的專業服務。就像那些在一段時間內推出了自己的Linux 發行版的公司一樣，他們給行業帶來的是某種程度的混亂，最終對行業和用戶是有害的。而且自己做也需要很多的資源。你需要有個 20-30 人的 Python 開發團隊，對基礎架構（計算、存儲和網絡）都非常熟悉，他們需要全時間投入到你自己定制的 OpenStack 上。一個團隊看起來大概象：
因此，最終地，如果你需要一個企業級 OpenStack 驅動的私有雲方案的話，你需要選擇一個廠商。
需求4 - 混合雲兼容
混合雲是個全新的世界。我們所交流過的大部分客戶都已經意識到，他們需要向其開發人員提供最好的工具。需求不同，要求不同，想法不同，抱怨也不相同。每個企業都是獨一無二的。有些企業希望從公有雲開始，然后一段時間后再轉移到私有雲；有些希望從私有雲開始，但是也緩慢的采用公有雲；而有些公司在兩個方向上齊頭並進。RightScale 2014 年的報告對這方面有些非常好的調查數據支持：
我們來看看，為什么你的企業級 OpenStack 驅動的雲操作系統提供商最好有一個優秀的混合雲故事可以講。
混合雲優先戰略
每個公司都需要一個混合雲優先戰略。這個的意思是，混合雲應該是你第一個的和主要的需求。然后，圍繞混合雲，使用一個單一的、整合的監管模型，會給你帶來最好的收益。最終，根據你的應用和需求，制定一個流程，來確定每項工作需要什么類型的雲。下面這個圖突出了這個流程，但是你要知道，每個公司情況不同因此數據也不會相同：
理解雲的兼容性和企業級私有雲在混合雲中的角色
我做過不少兼容性方面的事情，最痛苦的莫過於 IPSec 和 VPN 之間的兼容。達到各廠商之間的兼容性是需要花成本的，往往需要大量的工作，而且往往最終很難取得一個好結果。而且不幸的是，兼容性往往被誤解，特別是對於公有雲/私有雲/混合雲。
混合雲的挑戰，是如何解決應用的移植性問題。如果你需要一個公有雲和私有雲組合而成的混合雲，不管應用在某個雲中被開發，還是要在兩個雲之間做遷移，或者從一個雲到另一個雲，應用的可移植性都是必須的。當你選定一個應用以及它的雲原生的自動化框架，並將它們從一個雲移動到另一個雲中，一些關鍵的東西必須保持一致：
- 性能相對平穩
- 底層的存儲、網絡和計算架構保持一致或者近似
- 你應用的自動化框架必須和兩個雲中的 API 都兼容
- 每個雲中，運行應用的總成本（TCO）都應該在1/2-2倍的范圍之內
- 還有行為上的兼容性，意味着非 API 功能也需要吻合
- 支持與相關公有雲 API 的兼容
下面這個表格將有助於解釋這些需求：
當然，當你設計你的應用的時候，你還需要考慮避免和特定雲的鎖定，比如避免依賴 AWS 上的 DynamoDB，VMware 上的 HA/DRS，F5 上的 iRules 等等。
如果你不能滿足這些需求，是無法獲得兼容性的，應用的移植肯定會失敗。應用的性能可能會在不同的雲上變化很大，其中一個雲上會最好；某些雲可能缺少一些功能特性使得你的應用不能工作；如果沒有行為上的兼容，你的自動化框架可能會不能工作。打個比方，如果應用中有個定時器，它假設虛機會在 30 分鍾內啟動，可是在一個雲上虛機過了一到兩個小時才啟動起來。
所有這些問題，必須通過混合雲兼容來解決。
OpenStack 需要一個參考架構
Linux 內核需要一個參考架構。實際上，每個 Linux 的主發行廠商都創造了自己的參考架構，因此，我們現在有不同的 Linux 操作系統分支。比如，有RedHat/Fedora/CentOS 分支和 Debian/Ubuntu 分支。這些純粹的 x86 操作系統都有各自的參考架構型，在每個類型內的遷移是相對不需要怎么花費力氣的。但是，當 RedHat 管理員去使用 Debian 時，他可能會有些迷茫，直到他完全知曉了兩者的區別。OpenStack 的情況其實也沒什么不同。
OpenStack，就像它的大多數開源同胞一樣，是沒有參考架構的。它只是雲操作系統的內核。這既是它的優勢，也是它的劣勢。Linux 也是一樣的。你可以給你的超級計算機獲得 Cray Linux，你還可以給嵌入式 ARM 設備獲得 Android。兩者都是Linux，但是都有不同的架構，使得應用在兩者之間無法遷移。OpenStack 是類似的，總有一天，大部分的 OpenStack 雲之間沒有兼容性，因為每個都有自己的架構。每個雲都有自己的架構，是注定要成為 OpenSnowFlake（櫃台里面各種不同款式的鑽戒）。
OpenStack 驅動的企業級雲操作系統需要有共同的參考架構。只有這樣，你才能確保每個部署的雲實例，都能和其它雲實例兼容。目前，這些參考架構還沒有出現。然而，假設 AWS 和 GCP 有一個單一的雲參考架構（我們稱之為“彈性雲參考架構”），我們很難想象沒有任何 OpenStack 參考架構會和這種架構非常類似。
說得更清楚一點，將來肯定會有多個參考架構最終脫穎而出。我也看到了在高性能領域出現的架構，以及別的行業比如石油和天然氣行業。
企業級參考架構
最終，你需要打賭 OpenStack 企業級參考架構會在哪里落地，但是目前的數據表明，前10大公有雲中，只有一兩個是基於 OpenStack 的。
如果企業希望敏捷、靈活和多選擇，看起來顯而易見，OpenStack 需要支持一種企業級參考架構，該架構會致力於打造和公有雲領域的終極贏家兼容的混合雲。這只是我的個人意見，目前看起來象 Amazon, Google, and Microsoft。
企業級 OpenStack 意味着一個企業級的參考架構，它會保證混合雲兼容性和應用移植性。
第二部分總結
設計一個提供混合雲兼容性的開放架構是目前的一個結論。可能對於如何實現會有爭論，但是對於實用主義者來說，可以肯定的是，公有雲領域將會出現各種贏家，而且前十名的公有雲已經被非OpenStack方案占據了。我們需要做相應的准備。
更重要的是，當你期望一個企業產品的時候，記得要求一個開放的架構。
下一篇文章中，我們講探討為下一代應用交付一個性能優異的、可擴展的和彈性的基礎架構具體是指什么。
原文：The 6 Requirements of Enterprise-grade OpenStack，Posted on Apr 28, 2014 by