【編者按】本文是一封致OpenStack社區的公開信，由OpenStack社區發起人杜玉杰（@ben_杜玉杰）編譯，以下為公開信全文：

親愛的Stacker們，

在過去的三年里，OpenStack社區彌漫著武斷和不公平的定位，尤其是對于AWS和VMware。這種觀點最現實的表達就是OpenStack應該建立和維護一套它自己的差異化的API。

我毫不掩飾自己的信念，那就是這一選擇將傷害OpenStack，或許已經帶來了傷害?，F在，這個問題變得更加嚴峻，我希望能夠說服你們支持我的觀點，那就是OpenStack應該立即擁抱既定的公有云API和特性。這對于OpenStack的成功至關重要，更重要的是這樣做才真正符合OpenStack的使命。

為了說服你們，我首先會介紹一下有關差異化的API集合的這段歷史，然后，我們再看看為什么AWS和GCE支配公有云是不可避免的。我會揭穿圍繞著有關抄襲這個公有云API的所有謊言，最后，我們將直擊云計算中“創新曲線”的胡言亂語。

我們為何淪落到如此地步？

當OpenStack在2010年夏天發布的時候，在它最初的兩個模塊中并沒有“native”API。Nova最初只提供EC2 API。該部分是由NASA貢獻的，側重于重新打造一個兼容EC2的私有云系統。Rackspace API是在EC2 API之后添加進來的，也就是在2010年那個夏天，OpenStack項目發布不久之前。

請注意，在NOVA項目中沒有任何描述提及過“native APIs”以及對目前的NOVA[README]的比較。

該項目的另一半Swift，使用它自己原生的API，其中一部分，也就是最初的Swift代碼是來自于RackSpace的Cloud Files服務。

簡單來說，OpenStack最初的“native”API，其中一半是AWS兼容的（NOVA），另一半是RackSpace公有云兼容的（Swift）。

然后，RackSpace并購了ANSO Labs ，從而實際上“擁有了”OpenStack代碼另一半的貢獻者。更重要的是，大多數能夠決定該項目技術方向的項目團隊負責人（PTLs） 都成為了RackSpace的員工。

在并購ANSO Labs的這段時間里，RackSpace的API才被更改為“nova-api”，這就是現在所謂的Nova的“native API”。 該API在很大程度上與RackSpace Cloud Servers公有云服務的API是一致的。至今這個API變動不大，并且深深的影響了這個項目的命名法則（例如，“floating IPs”與“elastic IPs”) ，并在某種程度上影響了Nova的方向。

根本沒有什么所謂的“native”API。事實上，把RackSpace Cloud Servers API稱為“native API”是在宣揚一個概念，有一個OpenStack Nova API是獨立于Amazon API的。現在很明顯，事實上最初的OpenStack native API就是它的AWS EC2 API。

我們來控制OpenStack

自2010年上述決定做出以來，OpenStack項目的管理已日趨成熟。OpenStack基金會，一個獨立的組織，目前主導著OpenStack的戰略和商務方向，而其開發團隊的技術精英在主導該項目的發展方向。

簡而言之，社區控制著該項目的方向，并且是時候主張按照符合我們的最佳利益策略來兼容公有云了，而不僅僅是由一個單一的，雖然是主要的貢獻者來主導了。如果不能改變這個策略，最終很有可能會導致這個項目變得無足輕重而死去。

亞馬遜主宰公共云

很明顯AWS（也有可能是GCE）將完全主導公有云的競爭。但更重要的是，who cares？AWS和GCE主導并不意味著OpenStack失敗。事實上，OpenStack很明顯正走向“贏得”私有云的競賽的道路上，并且快速擁抱Amazon將使得OpenStack處于主導混合云的關鍵位置。

在2011年二月的Cloud Connect大會上，我做過一個主題演講，勾勒了“兩個云的故事藍圖”，用數字比較了AWS和RackSpace Cloud Servers的規模和增長。在那個時候，我相信是RackSpace的年增長率給他們打了一劑強心針，使得在公有云的市場上他們被放在了AWS的死對頭的位置（當時AWS年增長率是100%而RackSpace是90%）。

但在這之后的兩年半的時間里，變化太大了。AWS的增長率有增無減，GCE正式加入競賽。與此同行，RackSpace面臨著增幅下滑。如果RackSpace今年Q2-Q4的盈利等同Q1，他們的公有云將從最高90%的年增長率下滑到30%，在過去幾年中出現驚人的跌幅。請參閱下圖，假設2013年季度財季增長保持不變。

雖然沒有關于GCE的增長率的公開信息，但我相信它與AWS是持平的?？蛻魧λ麄兊墓性品盏呐d趣是如此之高，以至于他們等待列表中的客戶數量已經大于實際上大多數生產環境中的公有云客戶名單數量。而他們還仍然處于內測階段。

是什么導致RackSpace公有云的突然下滑？ 從公布的信息來看， AWS，很可能是GCE正在領跑公有云服務，并且給OpenStack社區一個顯而易見的選擇。

Amazon控制著公有云的創新曲線

2010年時，一些人認為標準化RackSpace公有云API將允許OpenStack控制創新曲線，而不是Amazon的創新曲線。從那時起，Amazon繼續推新功能，并以驚人的速度整合到產品中。很簡單，他們控制著公有云的創新曲線。AWS的競爭對手所添加的每一個公有云特性都將直接與AWS已經內置的功能進行對比。

OpenStack可以在私有云和混合云中的創新曲線中起主導作用，但這需要我們支持公有云中領先的創新曲線。OpenStack要想主導私有云和混合云的創新，它必須擁抱企業希望聯合的公有云。

OpenStack可以主導混合云的未來

雖然我曾經批判了這一觀點，我曾經認為私有云和公有云需要看起來一樣并且互聯互通，如果我們大量的采用云?，F在我們看到企業客戶需要混合的云解決方案：連接到公有云的私有云，這樣他們就可以在兩頭運行工作負載，并且可以有所選擇和控制，以積極推動經濟和業務敏捷性。

有爭議的或許是一套基于OpenStack的公有云服務是否會成為這個公式的另一半。在這一點上有這樣的公有云的可能性似乎降低到了微乎其微。AWS和GCE的地位已經確立，全球影響力，快速的功能迭代和增長率奠定了他們的領先位置。有什么可以阻擋？坦率的講，在技術雷達上已經沒有競爭者。

在AWS和GCE主宰的公有云市場里，希望提供一種混合選項的私有云必須接受這些領跑者。

這一切導致一個必然的結論：OpenStack的未來必將是成為與主流的公有云兼容的混合云，這些主流的公有云就是AWS和GCE。如若其他情況出現，我們只有當他們的市場地位已經確立時才需辯論和評判。

因為類似甲骨文和谷歌在Java虛擬機與Davilik虛擬機的裁決，法庭很可能無法保護公共的API。

法律上的恐懼毫無根據

在公有云的API保護上的恐懼、不確定和懷疑完全是愚蠢的。阻止OpenStack社區復制AWS和GCE API是沒有法律依據的。要牢記的是Amazon的API已經被復制了。他們有能力針對因此受到的影響而成功地采用一個新的法律措施，事實上之前他們并沒有反對復制API。

整個OpenStack社區受益

擁抱Amazon符合全體社區成員的利益，把OpenStack定位成為企業和SaaS提供商的最佳選擇，他們希望有這么一個公有云生態系統，這樣他們的應用在任何時候都可以部署到最適合它們的基礎設置中。

換句話說，如果基于OpenStack的公有云擁抱主要的公有云API，它們會受益于AWS的生態系統，它們將可以在這份大蛋糕中切到一塊。同樣，主機托管公司也有機會出售托管的私有云，并且是和公有云兼容的，也解決了企業的混合云問題。事實上，這可能是RackSpace夢寐以求的目標。

正是出于這個原因，RackSpace也將是我的倡議受益者。他們將處于一個特殊的位置，將能夠部署私有的托管OpenStack 混合云，并且是兼容客戶任何想要的公有云的混合部署方案。

現在是時候擁抱Amazon和AWS API 啦！

是該OpenStack社區做出抉擇的時刻了，選擇一個兼容公有云的策略將使得該項目能夠主導私有云和混合云市場。

時間非常關鍵。AWS已經涉足提供私有AWS regions給政府（AWS GovCloud），甚至是特殊機構（CIA/NSA）。有理由推斷，他們可能會擴大這項計劃，必將威脅到OpenStack目前所處的機遇。

我的倡議如下：

1. 擁抱主流的公有云API，GCE、AWS、Azure，甚至vCloud ；

2. 重新命名Nova API為Rackspace Cloud Servers API；

3. 創建一個新的低級別的API并且一道橋接的API模型；

4. 展開測試和refstack周邊工作 ；

5. 擁抱現有的AWS互操作性測試架構，例如Cloudscaling aws-compat和Eucalyptus eutester庫。

AWS和谷歌是我們的朋友，因為他們傳播和采用云計算。他們在為我們所有人“做大蛋糕”。他們共同創造一個豐富并且充滿活力的公有云生態系統，OpenStack可以通過一個同樣豐富和富有活力的私有云生態系統與之共舞。我希望OpenStack將能主導混合云解決方案。請幫助我使之成為現實。

Sincerely,

Randy Bias

原文鏈接：http://www.cloudscaling.com/blog/cloud-computing/openstack-aws/

譯文鏈接：http://duyujie.org/post/56367280481/openstack-amazon-openstack