雲計算新標：API介面選擇無國界限制

不管是公共雲服務使用者還是私有雲使用者都面臨管理伺服器併發請求數上限的任務。 由於基礎結構本身就是一項服務，IT人員創建併發處理請求上限，管理上限，通過控制台和應用程式介面來維持負載均衡及存儲管理。 不同的雲供應商提供截然不同的應用程式介面。 雲應用程式介面標準缺失，IT專家怎樣才能實現有效控制，使其與當前服務接軌，並與未來雲服務保持相容。

不少組織已經開始試探為雲計算建立一個標準化的應用程式介面。 DMTF（分管任務力量）就是一家具備創建雲標準動機的組織。 他們創建的草稿名為雲基礎結構管理介面模型及遠端程序呼叫的REST應用程式介面。 歐洲組織ETSI已經發表數篇關於雲技術和早期應用程式介面的研究著作。 比起雲計算，早期的應用程式介面更適用于網格計算。 公開網格論壇產生了雲別（不同的雲，不同的功能及特點）應用程式介面；然而，這一方案仍處於雛形狀態，因其沒有提供流量監控方法或價格計算方法。 具體的功能仍在開發中。

SimpleCloud，是Zend科技旗下公司，Zend科技同微軟和Rackspace一同創建了基礎版簡易雲應用程式介面（Simple Cloud API）。 儘管如此，這些動態只能說明雲應用程式介面產業正在起步，就標準化作業而言，很多供應商還沒真正開始上路。 典型的當屬亞馬遜網路服務公司（AWS），AWS已花費數年時間開發專屬功能基礎結構及雲應用程式介面，他卻沒有任何意向投身于標準化工業產業。 其他一些雲投資商已經開發出自己的標準，比如有Elastic Hosts應用程式介面，FlexiScale應用程式介面，GoGrid應用程式介面和SunCloud應用程式介面。

另外，Rackspace開發的openstack —— 一種資源分享雲軟體，本身是一個完整的基礎結構——而不僅僅是應用程式介面，這種全新模式也正蓬勃興起，勢頭蒸蒸日上。

集中雲管理和資源庫

一些公司開發了自己獨有的基於網路的雲併發請求數量上限管理產品，儘管都是一些不知名的雲投資商。 例如，RightScale公司配置了一個管理平臺，它提供一個單一的應用程式介面；還配置了一個管理平臺，這一平臺可與多個雲開發商並行工作。 另外有些雲開發商繞過建立標準化應用程式介面這一關卡，取而代之的是，提供一個庫可供大型雲使用者使用並具有簡易應用程式介面（API）。 庫的功能就像一個翻譯器，程式設計者可以在庫裡鎖定一個應用程式介面，然後精確到某個指定投資開發商。 Apache Deltacloud是一個共用雲庫，它與多個雲平臺交換資訊，包括亞馬遜，Rackspace，Gogrid和Rimuhosting，還可與利用OpenStack和VM 軟體vSphere建立的私有雲共用資訊。 同樣，jcloud有單獨一個應用程式介面，支援絕大部分主流雲供應商，包括AWS，還有使用Openstack的供應商。

選定一個雲應用程式介面意見：

目前業界沒有一個雲標準，而且我確定在未來可預見短期內也不可能形成一個標準。 儘管不少機構致力於開發一個標準化雲應用程式介面，標準終究只是部分成形，且僅獲得了少數幾家雲開發商的認可。 那麼開發商在選擇應用程式介面的時候該怎麼做呢?以下是一些指導原則：

如果你的雲服務商使用的是自主研發的應用程式介面，如AWS，那麼你將可能被這個供應商困住，以致無法擺脫。 但是，若你從未打算更換雲服務商，那麼這個選擇非常合理。 若你看中好幾家雲服務商服務，你就可以使用來自RightScale的協力廠商雲軟體來獲得服務。 儘管這是個好方法，其昂貴的花費使其使用物件僅限於大型企業。 這種產品包含功能特性明顯的應用程式介面，同時可以享受線上控制桌面和客戶服務。 那些預算有限又想聯合使用不同投資服務商的公司，資源分享雲工具如Delta雲和J雲就不失為好的選擇物件。 但是，這也有局限性。 局限性在於這些公司需要長期雇用一名專家從事維護開發工作，這大大增加了資源分享選項的成本。 正確的步驟應當是先確定一個標準化的應用程式介面，然後根據雲供應商的應用程式介面服務範圍選取雲供應商。 就目前來看，OpenStack是這一規劃的主導力量，然而這項工程正日益獲得其他投資服務商和客戶的認可。 但是注意，先選擇API再決定服務商固然可行，服務商的選擇範圍卻大大地受到限制。 同時限制了專屬功能的開發實現。

(責任編輯：蒙遺善)