云计算已经刮起了流行旋风，随着其不断成熟，应用不断增长，新用户涌现。在IT业界软件即服务和基础架构即服务愈发如鱼得水。但是因为云洗白和市场不成熟，平台即服务仍旧处在黎明前的黑暗中。
对软件即服务(SaaS)这样特定类型的应用，以一种方式访问复杂应用轻而易举，而且无需大量现金支出，只需要很低的管理支出即可。同样，基础架构即服务(IaaS)吸引了越来越多的企业，提供了一种访问多种且大量计算、存储和带宽资源的能力，而且可以像本地基础架构那样受到控制，无需先期投入。
平台即服务(PaaS)则是完全另一幅光景。主要受到前瞻性的开发者的拥戴，PaaS的主要价值定位在于增加了生产率以及更快的部署时间。PaaS也提供了内置的自动扩展和故障恢复，如果开发者想要在其应用中增加这些功能，则不需要学习这些复杂的代码。
“结合了预制OS和开发平台，应用部署就变得轻而易举，”Roger Jennings说道，他是OakLeaf Systems的首席咨询师，同时也是一位.NET开发者。尽管大多数IT人士自然而然的趋向于用IaaS满足自身需求，但是在微软的Windows Azure PaaS上只需要十分之一的时间即可搭建一个网站。
雾里看花 巧辨真假PaaS
当今，PaaS市场只是整个公有云市场的一小部分。但是如果PaaS飞黄腾达，很多专家也确信会是这样的结果，它将对IT人士产生广泛的影响，他们的角色和职责也会发生转变。但是市场仍旧处于初期，对于企业IT而言，很难预测会有多少应用、什么类型的PaaS平台，以及PaaS内置的应用是他们可能需要落地的。
PaaS剖析
大多数IT部门需要做的第一件事就是了解真正的PaaS和假冒的PaaS之间的区别。
“你否记得我们过去看到的所有的云洗白都是来自基础架构提供商?”James Staten说道，他是Forrester Research的以为分析师，“在PaaS领域其实更为糟糕。”
Staten解释道，他经常看到一些厂商尝试将IaaS的上的老一套，在增加一点服务就变成了PaaS，让开发者和运维人员甘傲困惑。
从核心观点将，真正的PaaS平台必须包含抽象的运行时环境、应用服务器、缓存层、整合开发工具，增加自动扩展以及故障恢复功能。用一个老一点的术语——中间件，它可以在公有IaaS之上运行，或者通过在本地硬件上运行实现交付。
真正的PaaS包括但不仅限于，比如微软Azure、Engine Yard、Heroku、CloudBees和Google App Engine。亚马逊Web服务(AWS)的Elastic BeanStalk，尽管经常说自己是PaaS，却完全对不起自己的账单，不符合PaaS的规则。
“Elastic BeanStalk就一个如何在IaaS上部署复杂应用的脚本，增加了一些故障恢复和可扩展的脚本，”Staten说道。相反，真正的PaaS并不提供脚本，但是暴露出可以为应用所调用的组件。
真正的PaaS和假冒PaaS之间的区别不止是学术上的差异;对于开发团队会产生实际的影响。对于那些相信自己就是在PaaS上开发的开发者来说，期望是“我编写我的代码，我来部署，可以自动化扩展而且能够自动化实现故障恢复，”Staten说道，而假冒的PaaS则是“应用无法真的扩展和实现故障恢复。”
PaaS平台来源
很多PaaS平台都起源于具体的编程语言。随着时间推移，大多数PaaS厂商都开始超越单一的语言，提倡多语言。然而，值得我们铭记的是，要找到适合你的环境的最适合的选择。下面是一些PaaS厂商以及他们的原始开发环境的不完全列表。
AppFog——PHP
CloudBees——Java
CloudFoundry——Ruby on Rails
Engine Yard——Ruby on Rails、PHP
Google App Engine——Python
Heroku——Ruby
Microsoft Windows Azure——.Net