在雲應用的初期，PaaS服務使用者提出了其應用的可攜性問題

醉風雲博客

很少企業能夠忍受將自己的應用開發實踐同單一廠商綁定，但是很多企業又在不知不覺中將應用開發和唯一雲供應商綁定在一起。

隨著雲越來越具有競爭力以及一些供應商具有長期穩定性風險，開發者必須理解如下的事情：即平臺即服務(PaaS)是圈套，因為平臺特性支援不均衡，一些PaaS供應商比其他的供應商造成了更大的風險， 所有的PaaS選擇通過正確的專案步驟都可以變得對於可攜性更加友好。

即便是在雲應用的初期，PaaS服務使用者提出了其應用的可攜性問題，而不是向PaaS供應商提問，而是在從第一個供應商轉向不同的供應商時提問，或者甚至是遷回資料中心時才提問。 在一些案例中，這種轉換要求軟體的主要改變，而且導致專案滯後，甚至生產力損失。 主要是兩個具體問題導致的，開發者必須在為PaaS創建可攜性應用時解決。

PaaS可攜性的第一個問題是缺少PaaS供應商之間一致的平臺定義。 使用基礎架構即服務(IaaS)，開發者同裸機共事，可以提供應用需要的所有系統軟體。 這種平臺的問題就是可攜性，因為從一個IaaS供應商遷移到另一個時，甚至會移植到本地內部的虛擬機器。 使用PaaS，供應商選擇自己支援的作業系統和中介軟體元素，如果供應商做出不同選擇，隨後應用在這些不同領域使用的性能就不能遷移。 如果一些PaaS性能是供應商自定制的，將應用遷移會本地相同的平臺甚至更難。

對於這個可攜性問題的最佳解決方案就是創建一個平臺參照點。 PaaS服務通常都是圍繞一個作業系統提供的(比如，Linux、Windows)，一群中介軟體用於通信和資料庫服務，還有管理和開發工具。 同時多種雲供應商可能提供相同的基礎平臺，變換了中介軟體和工具，因此繪製你優先的平臺類型性能圖表很重要，高亮標出哪些不統一支援的性能/工具。 避免這些性能和工具，就能避免可攜性問題。

第二個問題就是缺少可靠平臺替代供應商。 當今PaaS服務通常提供兩種形式。 首先，平臺「擁有者」(微軟的Windows/Azure為例)可能會對有效的伺服器平臺提供一個雲版本。 在這種案例中，第一類PaaSi工商的優勢可能也會阻礙競爭力，儘管平臺供應商考慮到了(微軟最近變更了Windows Server，促進非微軟Windows PaaS產品。 )

當一個支配性的供應商壓制PaaS競爭力，雲使用者可用的唯一替代物就是使用IaaS服務，包括其機器映射中的PaaS「平臺」部分。 如果這樣做，關鍵就是確保所有的PaaS性能對於本機伺服器配置可用。 主要平臺供應商(比如微軟、IBM、HP或者甲骨文)的風險就可能僅僅避免小型PaaS業務，但是在這些地方小型供應商就是PaaS唯一的選擇，計畫IaaS退路是個謹慎的過程。

第二個問題的解決方案就是配接器設計模式。 雲端應用必須參照可能不是所有供應商都可用的服務時，封裝參照到更高層的軟體元素中(遵循配接器設計模式原則，共有物件導向設計)並轉換通用需求到PaaS服務需要的具體形式。

例如，假設一個應用為亞馬遜的Redshift倉儲服務開發。 然而IaaS服務和廣泛使用的亞馬遜EC2相容，其他的IaaS供應商不提供Redshift，且應用是為了「miniPaaS」編寫，EC2/Redshift在不變更所有的專案參照到Redshift的情況向下就不能遷移。 一個開發者編寫了一個小型的軟體物件，稱之為「Warehouse」，用於代替Redshift應用程式介面(API)。 Warehouse內部，代碼可能改變資料庫指令引數，成為Redshift格式，隨後調用Redshift。 如果應用隨後轉移到一個不支援Redshift的供應商，Warehouse就要變更來執行正確的資料庫訪問API需求來類比。 Warehouse物件單一的變更就可以進行應用遷移。

這種基於抽象的機制也適用于管理應用可攜性問題，即需要在一個平臺性能上構建一個雲應用，競爭分析顯示並沒有廣泛的支援。 關鍵在於確保至少要有合理的方式在多種平臺上提供同樣的性能/功能，即便相同的API不能跨平臺工作，比如上面提到的Warehouse例子，在一個或者更多的替代平臺上根本沒有可比較的服務， 然後配接器設計模式機制在它們之中並不能輕鬆的支援可攜性。

久而久之，PaaS最大的可攜性風險並不是正常的PaaS平臺，比如Azure，但是隨著IaaS服務通過增加一些性能發展成PaaS服務，比如亞馬遜的Redshift或者快取服務。 這些平臺的很多使用者永遠不會把自己看作是PaaS使用者，可能在他們第一次嘗試將應用轉移到另一個供應商時就會被不可攜性攻其不備。 少量的預先計畫可以防止主要的問題，經驗也能夠協助雲專家要理解可能讓PaaS可攜性成為性能區別持久壓力。

(責任編輯：admin)