某些PaaS产品有一些特定的功能，将用户和他们的应用限制于某个特定的厂商。可以考虑使用容器等技术来增加PaaS的灵活性。
虽然基础架构即服务仍然是公有云产品的标准，用户却开始越来越对平台即服务感兴趣，因为它可以降低成本并简化操作。但大多数PaaS产品都有专门的操作系统或中间件功能，意味着可以将用户锁定到特定的供应商。
一个可移植的PaaS产品——即能够跨多个云平台和供应商工作，可以提供一个解决方案。组织有几种方法可以实现PaaS产品的可移植性。但首先重要的是要了解PaaS采纳背后的推动力。
用户采用PaaS模型主要有以下三个原因：
1.由于PaaS中包括了操作系统和中间件，进而降低了许可和支持这些元素的成本。这种降低可以抵消PaaS和基础架构即服务(IaaS)之间的差价。
2.PaaS包含的服务对所有应用都是标准化的，这可以简化混合云的部署。
3.某些IaaS云，如亚马逊网络服务，有一些非常有用的Web服务，可以创建一个PaaS环境。IT团队和开发人员可以将这些服务添加到应用中来改善性能或功能。
重要的是便携式的PaaS模型在这三方面是如何组合的，以及如何能够在各种公有云和私有数据中心环境之间移动。但是，想要以单一的PaaS方法来解决所有这些需求是很困难的。因此，企业需要优先考虑他们的PaaS目标，或者做好将多种方法结合起来的预期。
四种方法实现便携式PaaS模式
想确保你的PaaS环境可以跨多个云或数据中心工作的一种方法是采用容器技术，比如Docker，来托管应用。容器的架构会共享一个操作系统，但为每个容器提供一个中间件和文件系统的副本。在大多数情况下，包括Docker，我们有可能将中间件标准化使其可以横跨各个容器镜像，但我们也可以选择为应用和组件创建独立的容器镜像。之后开发团队便可以在多个环境间移动这些容器，并在任何相同类型的容器系统中，无论是托管在云或是数据中心，运行这些应用和组件。
市面上有许多开源软件工具能够增强Docker，使之更加的类似PaaS。比如DEIS，Flynn和Tsuru就是一些很好的例子，而且都相当容易使用。他们能够提高Docker在跨多个云提供商的容器中部署应用的能力。
另一种能够实现便携PaaS模式的方法是选择拥有宽容的许可证条款的操作系统和中间件组件——也就是在每个副本的基础上有适度定价，或多次使用的折扣，然后在你的云托管和数据中心组件中将他们标准化。你将在使用IaaS虚拟机或基于容器的云服务间进行选择。然后，你可以使用创建机器镜像或容器镜像的工具来检查中间件和操作系统的版本，确保你在每处部署的都是相同的版本。
这种方法在云应用不断扩展，或当应用或底层的操作系统和中间件变化频繁时可能会成为一个挑战。这些复杂性会引入错误和更高的运营成本，除非有软件的支持来简化任务。IT团队可以使用扩展工具来进行支持，如在创建机器镜像方面家喻户晓的VMware工具，但是，在某些时候，我们则有必要寻找一种工具，其具体目标是建立一个PaaS的环境。
在跨多个云间采用PaaS的第三种模式是使用能够在IaaS或裸机服务器上部署PaaS的云技术。Cloud Foundry和OpenShift便是这类工具的例子，但更新的产品，如Morpheus，正在受到关注。这些云部署或管理的工具允许用户创建和部署基于标准的中间件和操作系统的应用程序。企业使用这些工具来创建一个可以跨云提供商边界或多种服务器类型的PaaS模式。这些工具能够融合操作系统和中间件，构建一个真正的PaaS，并处理版本管理和跨系统中间件更新的艰巨任务。但是，这些工具的学习和使用过程都很复杂，比较适合拥有大量技术支持人员的企业。
另外，虽然这种PaaS的方法提供了便携性并减少了在多云或混合环境中维护应用的运营负担，但却不会改变许可方面的费用。如果那才你使用PaaS的目标，则这种做法可能不是最合适的。
实现便携式PaaS模型的第四种方式同微服务有关。组织可以将需要用到专门的中间件的应用组件做成可被应用其他部分按需调用的服务。这么做会使中间件仅仅被限制在这些服务中，进而降低复杂性和许可成本并确保实施的一致性。IT团队也可以使用同样这种基于服务的方式来构建一个不是所有IaaS提供商都提供的私有版本的Web服务，让依赖于这些Web服务的应用能够在所有IaaS云上实现可移植性。
这种方法会带来性能的风险。中间件通常同应用高度集成，而将经常使用的功能分离作为服务会带来网络延迟和性能问题。但是，慎重选择目标并控制延迟可以使这种模式变得很有价值，特别是在跨云提供商间协调Web服务的时候。
没有一种便携式PaaS模型可以适合所有的情形，现在做不到未来也不太可能。好消息是，组织可以结合某些或几个选项来达到他们想要的PaaS效率，而不需将自己锁定于一个单一的云供应商。想打造***的PaaS模型可能需要一些时间，但会很值得。
