今天市场上有越来越多的运动或势头将云服务从基础设施即服务(IaaS)转移出去。在云服务层次结构中，价值链上游的下一个选项是平台即服务(PaaS)。与IaaS托管和运行虚拟机并需要用户提供操作系统和中间件不同，PaaS提供了一个完整的平台，包括硬件和软件，应用程序在该平台上运行。PaaS可以实现更多的功能，因此可以为用户带来更多的潜在利益。正因如此，供应商才有信心定出更高的价格。PaaS可能是云服务从IaaS自然演变的下一个阶段，但实现它的方法可能不止一种。微软的Azure代表了一种利用现有数据中心平台并将其复制到云中的方法。第二种PaaS方法由CloudFoundry等工具支持：使用所选工具开发您自己的“平台”并进行部署。第三种方法由AmazonWebServices(AWS)支持，使用Web服务来补充或增强IaaS，从而创建“平台即服务”模型。从IaaS到PaaS的这三种途径各有千秋，因此决定采用哪一种途径意味着要深入研究细节。通过MicrosoftAzure通往PaaS之路要遵循Microsoft的PaaSAzure模型，您的云目标应用程序必须在数据中心的Microsoft服务器软件套件上运行或能够运行。所以这种方法的优势在于它可以与当前的软件策略相关联；用户可以轻松地从Microsoft服务器升级到Azure，因为云服务提供商也是本地软件平台提供商。确保两者同步应该简单直观。Azure方法的缺点是很少有数据中心服务器平台以一种形式广泛部署，因此除了Microsoft之外，很难展示这种方法实用的平台。微软拒绝向潜在的PaaS竞争对手开放其WindowsServer框架意味着一些Azure用户会感到被锁定在微软里面。目前尚不清楚微软将如何塑造Azure以添加对Windows服务器不重要的云服务功能，例如AWS现在提供的缓存服务。这种AzurePaaS模型的其他示例是基于Java虚拟机的云计算平台，这是一种可以在多种体系结构上运行的便携式平台。Amazon和其他公共云服务提供商提供托管的Java虚拟机和Java应用程序，它们几乎可以在任何数据中心或桌面系统上运行。然而，这种方法只有在目标应用程序是用Java语言编写的情况下才有效，这对许多用户来说是一个严重的限制。第二种结合PaaS与第三方工具实现PaaS的方法更为通用。CloudFoundry和OpenShift等工具允许用户从IaaS开始，添加操作系统和中间件工具来构建云计算平台。通过这种方法，用户能够让他们的应用程序在可靠的硬件和软件组合上运行。用户和应用程序生命周期过程免于维护平台软件。组合PaaS的问题在于您需要弄清楚谁负责构建和维护平台形象。公共云提供商可以使用工具组合来开发PaaS所依赖的平台，但提供商不太可能承担这种风险。供应商将不得不赌一把，看看是否有足够的应用程序可以在平台上运行，以获得可行的市场机会。如果使用组合工具的灵活性来构建多个平台，那么保持每个平台都是最新的是劳动密集型的，并且会增加管理成本。这些任务被推送给云计算用户。用户自己可以使用相同的工具来组合平台并使平台运行在IaaS上。如果这些工具允许用户自组织中间件和操作系统组件并使它们可用于应用程序部署，那么用户将受益匪浅。这是在操作系统或中间件更改时重新映像每台机器的替代方法。事实上，这是当今平台组合工具的主要用例。然而，为某个平台找到一个利基，让人怀疑这种方法是否会在公共PaaS中得到广泛应用。采用平台即服务方法的最后一个选择是平台即服务，这就是AWS今天实际做的事情。PlatformServices假定PaaS的目标是添加云优化或特定于云的服务，并在通过URL调用Web服务的任何应用程序中支持这些服务。这种方法的独特之处在于它针对的是为云更改或编写的应用程序，而不是从本地环境迁移的应用程序。这种着眼于未来的方法使平台服务成为公共云服务趋势的驱动力。平台即服务模型提供了更大的灵活性——类似于复合平台模型，但它结合了新的平台元素和关键的云计算应用程序特性。缺点是用户必须维护这些机器映像，因为此模型不托管正在运行的操作系统或中间件。添加像CloudFoundry这样的复合平台工具来管理这些元素将有望为用户解决这个问题。从理论上讲，像AWS这样的公有云服务提供商可以提供众多的平台服务，因此实际上有望定义一个云计算操作系统。如果是这样，本地平台提供商可能会决定支持它，以便利用新的应用程序，如果特定的开发工具可用于为该云操作系统开发应用程序，就像它为当前平台开发应用程序一样。在这种情况下，云可能会出现，将市场从云计算转变为本地平台，再到本地平台，再到云计算。英文原文链接：http://searchcloudcomputing.techtarget.com/tip/Three-ways-to-bridge-the-gap-between-IaaS-and-PaaS
