云服務的可用性和多樣性正在持續地增長中,越來越多的廠商提供著他們的平臺即服務、軟件即服務或基礎設施即服務。雖然私有云的概念還未對業界有多少的吸引力,但是混合云以及傳統內部部署應用程序和云托管服務的整合正開始成為企業的選擇。這一趨勢為企業架構師和CTO們在規劃把他們的IT業務遷移至云時提供了一個切實可行的選擇。
供應商為客戶提供的云服務層次各有不同,有的是以基礎設施即服務(IaaS)的形式提供原始計算能力和存儲資源,有的是通過平臺即服務(PaaS)產品托管定制業務邏輯組件,而有的則是通過PaaS針對特定業務問題提供一個完整的解決方案。所有這些云服務都存在著一個共同點:它們都需要使用某種類型的接口;雖然一個基于Web的控制面板看上去相當不錯,但是這種方式是無法真正地實現自由擴展以滿足大型企業應用的要求的,而這些大型企業又恰恰是云托管服務的主要用戶。正是由于這個原因,云供應商們所提供的API允許企業用戶以不同的方式與他們進行運行交互。
如同在作出所有的架構決策時一樣,當決定如何以及何時使用所提供的集成API時有很多需要考慮的因素,而API的可用性和適用性則是在選擇云服務廠商時需要重點關注的一個關鍵因素。以下部分將探討一些在選擇過程中需要牢記在心的一些關鍵考慮因素。
我是否需要供應商為我提供API?
對于這個問題的簡潔答案總是YES。即使一家公司的當前需求并不包括整合云服務,但是在未來不這樣做很可能會出現問題。因此,我認為API的可用性應當是在決定使用何種云服務時的一個關鍵因素。確定API是否允許企業與其他云服務整合,尤其是他們的競爭對手,即盡早明確供應商的API開放程度將是一個好主意。應考慮如何整合內部部署的服務和云供應商提供的服務。供應商提供的API使用了何種技術?API使用的是REST服務、SOAP、編程語言的庫,又或者是上述技術的某種組合?應當如何與你已開發的內部部署應用程序配合,以及如何進行整合?我還想要建議,企業應當審查API技術文檔的完備性。在行業論壇和討論組中關注其他同行對于API的常見抱怨。
第三方API
同樣,用戶也可以考慮是否可以采用第三方云API供應商的產品,這是實現服務交互的一個更好的方法,這是因為第三方API整合了很多供應商的后端。雖然選擇第三方API能夠更易于實現供應商更換、選擇具有最低成本或最適合特定需求的供應商服務,但是它實際上并不是一個杜絕企業對供應商依賴性的方法。目前,業界對于云集成API還缺乏一個標準,以對API供應商的依賴來取代對服務供應商的依賴仍然意味著要選擇使用一個合適的API。事實上,為其他云服務廠商提供API的企業也存在著某種依賴性,這就使得獲取實際價值變得比較困難。我認為,這些API不太可能繼續比那些服務供應商本身提供的API更具存在價值。
我應如何使用它們?
雖然首次使用云API的方法似乎是顯而易見的—整合云服務至其他內部部署系統或者其他的云服務—它們可能更為強大,但是正確使用這些API需要用戶多一些思考。一個系統配有具完備技術文檔的強大API是一種至高境界,而這是內部系統所難以企及的。預算并不允許開發人員編寫那些未來可能有用而目前不會帶來如何好處的API。但是,通過使用云服務,已經為我們帶來了使用集成API的麻煩。這就為大量的整合打開了一扇門,而這些整合工作在一開始并不明顯。當一個企業監控系統檢測到高需求時,可以將其與它的PaaS或IaaS供應商整合,并提供更多的容量。當企業收到一個高要求的出貨需求時,企業的庫存系統就會發貼至社交媒體。當授權服務與用戶之間的雇傭關系終結時,授權服務就會鎖定用戶的帳戶。當公司的所有服務已明確給出API定義時,只要整合API具有商業價值,那么整合的潛在可能性就會顯著增加。
當使用云服務時,另一個重要的決策就是使用哪一個API。大部分人都會使用一個現成的RESTful或其他的簡單HTTP API,而這正是進行整合工作最簡單的方法。但是,這些API的松散特性則意味著需要對API版本等因素予以重點考慮。如果一家企業已經在網絡服務上投資并將其作為一種整合技術,那么他們就可能會發現,一個基于SOAP或基于HTTP的服務提供了一個更為簡便的開發平臺,這是一個在組織內部更易于理解和實現的開發平臺。
但是,我們需要確保我們不會迷失在這個完全整合系統的夢幻世界中。這一領域還沒有標準,我們正在使用的所有API都是針對特定服務供應商的。最大限度地降低因供應商變更API、中斷服務或者甚至是玩失蹤所帶來的影響是非常重要的,我們希望能夠盡可能多地保持對這些API的控制,就如同這些API是我們自己開發的一樣。這正是傳統面向服務技術和方法的優勢所在,即無論這些服務是在云中還是在內部部署系統中,它都允許我們對我們服務的整合進行充分的掌控。
云服務API是云服務中吸引人的一部分,但是與所有的服務相同,在確定哪一個服務最適合某家企業之前,應當充分權衡具體實施方法的優缺點。