API在云上扮演著至關重要的角色，它讓應用可以和服務互相通信。但是當混合使用多個云供應商時，API的管理非常復雜。

云應用的開發幾乎總是依賴一系列來自頂級供應商的服務，比如Amazon Web Services、Microsoft Azure和 Google Cloud Platform。要想高效地訪問并且部署這些云服務，企業必須使用供應商提供的應用程序編程接口。

但是隨著企業引入混合和多云的戰略，管理以及集成這些應用程序接口(API)——供應商不同，API區別很大——面臨著極大的挑戰。本文研究該領域的關鍵問題以及解決方案，討論如何構建多云的API管理系統。

多云API管理系統的挑戰

所有API都不是一樣的——它們包括子程序、協議和工具的任意組合。

如果某個企業想要創建在多種云平臺上都能工作的應用的話，挑戰就會出現，因為供應商提供了不同的計算以及存儲實例、網絡服務和監控工具。這意味著使用這些互不兼容的服務方案時，在云供應商之間遷移一些工作負載甚至是不可能實現的。即使服務是類似的，用戶使用某個供應商的API調用服務的方式和操作和其他的供應商可能大相徑庭。

在向多云轉移時，管理員必須意識到供應商API間的不同之處。在不同的云供應商之間完成相同的任務所使用的API調用可能會多幾次或者少幾次。

不同供應商之間還存在著性能差異，比如延遲以及對給定時間內的API調用次數的限制。同一時間點，每個供應商底層的軟件棧，以及軟件棧調優或者優化的方式，也會影響到API的性能和可用性。這會讓應用的設計更為復雜。

另外，供應商通常使用不同的API安全和授權技術，以及不同的API錯誤消息。當云供應商增加服務以及更新API時情況會更加糟糕。

因為將單個API集成到企業應用所存在的這些挑戰，所以多云供應商的使用——以及創建支持該模型的API管理系統——將令IT人員望而生畏。

多云API管理系統的服務代理

解決多云兼容性難題的一種方式是API抽象，在應用和API訪問的多云服務之間插入另一層。該層向企業應用展現單一的、統一的API，使用單點登錄交付統一的命令集，比如提供創建和管理計算以及存儲實例的任務。這個抽象層隨后將這些命令翻譯成每種特定云供應商的API調用。

這樣抽象的API已經開始出現在多云管理市場里。比如，云管理供應商RightScale提供統一的API，可以管理大范圍的公有和私有云服務，包括Amazon Web Services (AWS)、Microsoft Azure、Google Cloud Platform、Rackspace、IBM SoftLayer、Apache CloudStack、OpenStack 和 VMware vSphere。這樣的通用API讓用戶可以創建出跨云供應商的一致的服務配置，同時提供覆蓋所有支持的云平臺的統一的監控，費用評估以及報告。

API管理軟件的優勢

然而，使用云服務代理或者API管理系統的問題是，添加另一層SaaS平臺所帶來的復雜度——以及對于業務而言會有另外的開銷。用戶也認為任意供應商服務的變更都會快速并且可靠地反應到代理的工具上。比如，如果AWS計費變更了，或者Azure添加了一種服務，代理就必須更新自己的平臺。用戶還必須適應代理的可用性和可靠性。如果服務不可用，就會影響到所有的云供應商服務的使用，直到代理恢復訪問為止。

向標準API進軍

理想狀態下，云供應商應該使用通用的API作為標準，來輔助多云上的應用和資源管理。雖然這聽上去是個很美的目標，供應商在這方面卻反應很慢，不愿意放棄對客戶的鎖定。但是，通用云管理API上的利益和關注仍然會隨著服務利潤的增長而增長。

一個新興的例子是，由Open Gred Forum的一個工作組領導的Open Cloud Computing Interface (開放云計算接口，OCCI)。OCCI構建了一個前端和服務供應商的管理系統交互。它最初是想遠程管理基礎架構即服務供應商，開發出通用的工具，可以使用一個API去部署，擴展以及監控服務。OCCI至今已經發展為可擴展的API，還可以服務平臺即服務以及軟件即服務(SaaS)的供應商。如今，OCCI已經實現了大量云堆棧，包括OpenStack、OpenNebula、CloudStack、the CompatibleOne云代理以及其他一系列工具，比如Eucalyptus。