本节书摘来自华章出版社《PaaS程序设计》一书中的第3章，第3.3节，作者 Lucas Carlson，更多章节内容可以访问云栖社区“华章计算机”公众号查看
3.3 走向公开标准
公开标准是平台即服务的一个重要概念，因为它们让开发者有信心独立完成与供应商提供的服务相关的应用部署。
需要了解每个不同供应商的来龙去脉完全是个噩梦。然而，我们已经讨论过了PaaS不同的类型和它们提供的不同种类的服务。
不可移植平台即服务开始时承诺“我们会向你的web应用提供Google的能力”提供不同解决方案，区别于可移植平台Heroku所说的：“零修改运行你的代码”。Heroku相对于某个平台是一套完全不同的解决方案，那个平台承诺:“我们为你打造可以在笔记本电脑桌面运行的你自己的平台。”每个供应商都在努力解决不同的问题，对于用户创建和部署应用的方式有完全不同的想法，从而产生不同标准，不一样的体验，以及不一样的展现。它们可能使用基于git的部署机制、REST API或者部署专用系统。有的可能支持持续整合，而有的可能关注部署工作。鉴于这些区别，很难以其中某一个作为标准。
3.3.1 开源的魅力
尽管一路走来出现很多不同类型的平台即服务技术，每天还产生很多新技术，最有可能从Cloud Foundry或OpenShift上产生新标准：一些提供开源选项的PaaS。
阐述这些技术的几个强有力的因素是：用户可以在自己的笔记本电脑上运行这些技术，这一点对尝试将PaaS整合到自己每天的工作事项的开发者们来说充满诱惑。PaaS开源社区的另一个好处是用户理论上可以在多个提供兼容PaaS选项的供应商之间选择，甚至自己在生产环境中运行。与之相反，除非Heroku开放其技术栈的源代码，否则用户必然被捆绑到Heroku选择的基础设施供应商。
总之，开源PaaS的这些有利条件为创建标准奠定基础，基于它们的API创建的标准不会限制用户使用特定设备或者服务提供商。它也扮演新兴标准的角色，指导用户如何以标准方式在公共和私有的基础设施上部署应用。
我们已经看到开始将Cloud Foundry API作为标准使用。AppFog用它在亚马逊 Web Services、Rackspace、HP Cloud以及Windows Azure上部署应用，这也验证了一个标准的API可以在不同后台使用。开发者通过Cloud Foundry API与这些系统交互，降低他们使用的API语言与底层设备之间的耦合度。
每天越来越多的PaaS技术变成开源的。Cloud Foundry是最早这样做的领头人之一，之后Red Hat开放了OpenShift、GigaSpaces支持开源云，甚至dotCloud在它的PaaS技术栈里开辟了一片开源领域。
3.3.2 评估旧应用
如我们看到的，现在有很多PaaS供应商，适用不同需求并拥有不同的理念。当我们考虑遗留应用迁移到云上的问题时，应当根据应用的需求考量不同平台的限制。在下一章节，我们会深入探讨将遗留应用迁移到PaaS上，并为用户可能会面临的一些困境提供解决方案。
