现在市场上关于将云服务的级别提升到基础设施即服务（IaaS）以上的动静或声势越来越大。在云服务层次体系中，价值链上的下一个选择就是平台即服务（PaaS）。不像IaaS托管运行虚拟机，并要求用户提供操作系统和中间件，PaaS提供了包括软硬件在内的完整平台，应用程序在该平台上运行。PaaS能实现更多的功能，因此它可以为用户带来更多的潜在好处。正是由于这个原因，提供商们有底气定更高的价位。

　　PaaS也许是云服务从IaaS自然进化的下一个阶段，但是具体实现的方法可能不止一种。微软的Azure代表了一条途径，拿来现有的数据中心平台，然后在云端复制。第二种PaaS方法由诸如Cloud Foundry之类的工具来实现：通过所选择的工具开发你自己的“平台”，并部署它。第三种方法得到了亚马逊网络服务（AWS）的支持，利用Web服务补充或增强IaaS，从而创建一种“平台服务”模式。从IaaS到PaaS的这三条途径都有其可取之处，所以决定走哪一条意味着要进一步深入了解相关细节。

　　经由微软Azure走向PaaS道路

　　想遵循微软的Azure模式实现PaaS，你那些以云计算为目标的应用程序必须在数据中心中的微软服务器软件套件上运行，或者能在该软件套件上运行。因此，这种方法的优势在于，能与当前的软件策略联系起来；用户很容易从微软服务器升级到Azure，因为这家云服务提供商还是内部部署型软件平台提供商。确保两者同步应当简单又直观。

　　Azure方案的缺点在于，很少有数据中心服务器平台是以一种形式广泛部署的，因而除微软以外，很难表明这种方法很实用的一种平台。微软拒绝向未来的PaaS竞争对手开放其Windows服务器框架，这意味着一些Azure用户会觉得被微软牢牢束缚。还不清楚微软会如何打造Azure，以添加对Windows服务器来说并不重要的云服务功能，比如现在AWS提供的缓存服务。

　　这种Azure PaaS模式的其他例子是基于Java虚拟机的云计算平台，这是一种可在多个架构上运行的便携式平台。亚马逊及其他公有云服务提供商提供托管的Java虚拟机和Java应用程序，它们可以在几乎任何的数据中心或桌面系统上运行。不过，这种方法只有在目标应用程序使用Java语言编写而成时才有效，这对许多用户来说是个严重的局限性。

　　使用第三方工具组合PaaS

　　实现PaaS的第二种方法更具普遍性。Cloud Foundry和OpenShift等工具让用户可以从IaaS入手，并且添加了操作系统和中间件工具以构建云计算平台。借助这种方法，用户就能够让应用程序在一套可靠的软硬件组合系统上运行。用户和应用程序生命周期流程则免于对平台软件进行的维护。

　　组合PaaS的问题在于，需要搞清楚谁来负责构建和维护平台映像。公有云提供商可以使用组合工具来开发PaaS所依赖的平台，但提供商不太可能冒这个险。提供商不得不赌一把，看看是否有足够的应用程序可以在这个平台上运行，从而获得切实可行的市场机会。如果组合工具的灵活性被用来构建多个平台，那么确保每个平台实时更新就很耗费精力，管理成本也随之增加。这些任务会被推给云计算用户。

　　用户自己可以使用同样的工具来组合平台，并且让平台在IaaS上运行。如果这些工具允许用户自行组织中间件和操作系统组件，并让它们可用于应用程序部署，用户将受益匪浅。这是操作系统或中间件发生变化时，重新制作每个机器映像之外的一种替代方案。实际上，这是如今平台组合工具的最主要的使用场合。不过，为某一个平台找到小众市场让人怀疑这条途径会不会广泛用于公有PaaS.

　　采用平台服务方法

　　最后一种选择就是平台服务，这是AWS目前实际采用的方法。平台服务假定PaaS的目标是，添加针对云计算优化的服务或者是云计算特有的服务，并且在通过URL调用Web服务的任何应用程序中支持这些服务。这种方法很独特，原因在于它针对的是为云计算更改或编写的应用程序，而不是从内部部署环境迁移过来的应用程序。

　　这种着眼于未来的方法让平台服务成为推动公有云服务发展趋势的因素。平台服务模式提供了更高的灵活性――就像组合平台模式那样，但是又把新的平台元素与重要的云计算应用程序特性结合起来。

　　不尽如人意的地方是，用户必须维护这些机器映像，因为这种模式并不托管运行操作系统或中间件。添加Cloud Foundry之类的组合平台工具以管理这些元素，有望为用户们解决这个问题。

　　从理论上来说，像AWS这样的公有云服务提供商可以提供众多的平台服务，因而实际上有望定义一个云计算操作系统。如果这么做，如果提供了特定的开发工具，就像针对当前平台开发应用程序那样针对该云计算操作系统开发应用程序，内部部署型平台提供商可能会决定支持它，以便充分利用新的应用程序。那样，云或者就会出现，将市场由云计算适应内部部署型平台，变为内部部署型平台适应云计算。