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

隨著云越來越具有競爭力以及一些提供商具有長期穩(wěn)定性風(fēng)險，開發(fā)者必須理解如下的事情：即平臺即服務(wù)(PaaS)是圈套，因為平臺特性支持不均衡，一些PaaS提供商比其他的提供商造成了更大的風(fēng)險，所有的PaaS選擇通過正確的項目步驟都可以變得對于可移植性更加友好。

即便是在云應(yīng)用的初期，PaaS服務(wù)用戶提出了其應(yīng)用的可移植性問題，而不是向PaaS提供商提問，而是在從***個提供商轉(zhuǎn)向不同的提供商時提問，或者甚至是遷回數(shù)據(jù)中心時才提問。在一些案例中，這種轉(zhuǎn)換要求軟件的主要改變，而且導(dǎo)致項目滯后，甚至生產(chǎn)力損失。主要是兩個具體問題導(dǎo)致的，開發(fā)者必須在為PaaS創(chuàng)建可移植性應(yīng)用時解決。

PaaS可移植性的***個問題是缺少PaaS提供商之間一致的平臺定義。使用基礎(chǔ)架構(gòu)即服務(wù)(IaaS)，開發(fā)者同裸機共事，可以提供應(yīng)用需要的所有系統(tǒng)軟件。這種平臺的問題就是可移植性，因為從一個IaaS提供商遷移到另一個時，甚至?xí)浦驳奖镜貎?nèi)部的虛擬機。使用PaaS，提供商選擇自己支持的操作系統(tǒng)和中間件元素，如果提供商做出不同選擇，隨后應(yīng)用在這些不同領(lǐng)域使用的性能就不能遷移。如果一些PaaS性能是提供商自定制的，將應(yīng)用遷移會本地相同的平臺甚至更難。

對于這個可移植性問題的***解決方案就是創(chuàng)建一個平臺參照點。PaaS服務(wù)通常都是圍繞一個操作系統(tǒng)提供的(比如，Linux、Windows)，一群中間件用于通信和數(shù)據(jù)庫服務(wù)，還有管理和開發(fā)工具。同時多種云提供商可能提供相同的基礎(chǔ)平臺，變換了中間件和工具，因此繪制你優(yōu)先的平臺類型性能圖表很重要，高亮標(biāo)出哪些不統(tǒng)一支持的性能/工具。避免這些性能和工具，就能避免可移植性問題。

第二個問題就是缺少可靠平臺替代提供商。當(dāng)今PaaS服務(wù)通常提供兩種形式。首先，平臺“所有者”(微軟的Windows/Azure為例)可能會對有效的服務(wù)器平臺提供一個云版本。在這種案例中，***類PaaSi工商的優(yōu)勢可能也會阻礙競爭力，盡管平臺提供商考慮到了(微軟最近變更了Windows Server，促進非微軟Windows PaaS產(chǎn)品。)

當(dāng)一個支配性的提供商壓制PaaS競爭力，云用戶可用的唯一替代物就是使用IaaS服務(wù)，包括其機器映像中的PaaS“平臺”部分。如果這樣做，關(guān)鍵就是確保所有的PaaS性能對于本地服務(wù)器配置可用。主要平臺提供商(比如微軟、IBM、HP或者甲骨文)的風(fēng)險就可能僅僅避免小型PaaS業(yè)務(wù)，但是在這些地方小型提供商就是PaaS唯一的選擇，計劃IaaS退路是個謹(jǐn)慎的過程。

第二個問題的解決方案就是適配器設(shè)計模式。云端應(yīng)用必須參照可能不是所有提供商都可用的服務(wù)時，封裝參照到更高層的軟件元素中(遵循適配器設(shè)計模式原則，共有面向?qū)ο笤O(shè)計)并轉(zhuǎn)換通用需求到PaaS服務(wù)需要的具體形式。

例如，假設(shè)一個應(yīng)用為亞馬遜的Redshift倉儲服務(wù)開發(fā)。然而IaaS服務(wù)和廣泛使用的亞馬遜EC2兼容，其他的IaaS提供商不提供Redshift，且應(yīng)用是為了“miniPaaS”編寫，EC2/Redshift在不變更所有的項目參照到Redshift的情況向下就不能遷移。一個開發(fā)者編寫了一個小型的軟件對象，稱之為“Warehouse”，用于代替Redshift應(yīng)用程序接口(API)。Warehouse內(nèi)部，代碼可能改變數(shù)據(jù)庫操作參數(shù)，成為Redshift格式，隨后調(diào)用Redshift。如果應(yīng)用隨后轉(zhuǎn)移到一個不支持Redshift的提供商，Warehouse就要變更來執(zhí)行正確的數(shù)據(jù)庫訪問API需求來模擬。Warehouse對象單一的變更就可以進行應(yīng)用遷移。

這種基于抽象的機制也適用于管理應(yīng)用可移植性問題，即需要在一個平臺性能上構(gòu)建一個云應(yīng)用，競爭分析顯示并沒有廣泛的支持。關(guān)鍵在于確保至少要有合理的方式在多種平臺上提供同樣的性能/功能，即便相同的API不能跨平臺工作，比如上面提到的Warehouse例子，在一個或者更多的替代平臺上根本沒有可比較的服務(wù)，然后適配器設(shè)計模式機制在它們之中并不能輕松的支持可移植性。

久而久之，PaaS***的可移植性風(fēng)險并不是正常的PaaS平臺，比如Azure，但是隨著IaaS服務(wù)通過增加一些性能發(fā)展成PaaS服務(wù)，比如亞馬遜的Redshift或者緩存服務(wù)。這些平臺的很多用戶永遠不會把自己看作是PaaS用戶，可能在他們***次嘗試將應(yīng)用轉(zhuǎn)移到另一個提供商時就會被不可移植性攻其不備。少量的預(yù)先計劃可以防止主要的問題，經(jīng)驗也能夠協(xié)助云專家要理解可能讓PaaS可移植性成為性能區(qū)別持久壓力。