很少企业能够忍受将自己的应用开发实践同单一厂商绑定，但是很多企业又在不知不觉中将应用开发和唯一云提供商绑定在一起。

　　随着云越来越具有竞争力以及一些提供商具有长期稳定性风险，开发者必须理解如下的事情：即平台即服务（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可移植性成为性能区别持久压力。