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

隨著云越來越具有競爭力以及一些提供商具有長期穩定性風險，開發者必須理解如下的事情：即平臺即服務(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可移植性成為性能區別持久壓力。