迄今为止关于云计算的大部分讨论都还只是集中于把应用程序迁往云计算的话题上。虽然云计算服务的增长速度是比较高的，但是这一发展态势甚至都没有让云计算相关开支占到企业IT预算的5%。云计算业界的领导者亚马逊网络服务（AWS）表示，还有另一条通往云计算成功的道路，也就是使用云计算来做那些在数据中心中做起来有困难、实现成本很高或者甚至根本不可能做的事。

　　这样一种平台服务的方式通过为应用程序增加云计算增强功能来扩展基本的基础设施即服务（IaaS），从而提出一个更为强大的云计算价值主张和更激动人心的云计算承诺。平台服务基本上就是网络服务，这种通过应用程序编程接口（API）提供的服务能够与其他应用程序实现紧密集成。因为平台服务看上去更像是基于API的互联网服务，从本质上来看，无论是在云计算中运行还是在数据中心中运行的应用程序,通过它们进行访问都是一致的。这就使得平台服务成为开发混合云计算应用程序的最佳工具。

　　如果一个平台服务是通过一个开放API提供的，而这个开放API是可以在数据中心（私有云计算或者甚至传统软件）中复制，那么当发生云计算高峰或故障转移事件时就可以把这个服务迁入或迁出云计算。这也就创建了一种全新的服务模式。

　　对其进行资本化运作的技巧就是要了解平台服务、评估实施这些服务的方案选项以及为基于平台服务的强化而设计应用程序。

　　抓住平台服务的精髓

　　对于一个云计算架构师或规划者来说，把平台服务视为一种平行化的SaaS是很自然而然的，因为它是一组支持具有共同技术特点和需求应用程序的工具，而不是单一的垂直化。（Salesforce.com 和 SAP是使用这一平行化的软件即服务元素的良好来源。）协作和统一通讯是SaaS工具被视为平台服务的两个示例，此外还有很多的AWS工具。

　　编制一份网络服务形式的平行化软件工具的目录可以从审查所有这些来源开始入手，然后围绕这些工具从头开始考虑进行应用程序开发。在你拥有内部组件化应用程序的地方，组件可以被填加至这些基础的平台服务框架的想法能够为你的业务需求提供更为专业的因素。

　　评估实现平台服务的选项

　　那些希望充分利用平台服务的用户所面临的挑战在于，这些服务并不是我们目前所认为的云计算的一部分。他们并不是目前应用程序的元素，所以他们无法简单地把这些应用程序迁往云计算。事实上，使用平台服务将几乎肯定需要用户付出一些开发方面的工作，它可以是由你自己的公司或者第三方承包商来进行。对于那些把云计算视为降低IT成本途径的人来说，这一点似乎是与其目标刚好相反的，但是平台服务所开发的应用程序具有与生俱来的容量弹性、更好的性能与可用性以及更好的用户界面性能和体验质量。其中的关键在于用户能够找到真正的平台服务。

　　当你对你的选项进行评估时，请记得所有真正有用的平台服务将以某些方式使用云计算。其中包括有用的管理服务（例如调度工具、集成等），可使用网络API提供这样的服务，它们可能与平台服务类似，但是它们不会扩展云计算的使用，它们只是在云计算中实现应用程序的迁移和管理。

　　平台服务评估的一个好做法就是审查亚马逊的服务目录，在目录中你将会发现管理服务扩展、在基本云计算数据管理中的数据库服务扩展以及所谓的应用程序服务，例如AppStream和Kinesis； Simple Queue Service，即SQS； Simple Notification Service，即SNS等等。它是代表了真实平台服务示例的那一组服务：让云计算应用程序成为更好应用程序的服务。未来的云计算用户应当探索这种类型的服务。

　　使用平台服务设计应用程序

　　云计算消费者所面临的难题就是，目前还没有平台服务的标准，所以缺乏这样的标准也就缺乏足够的速度和广度，这样也就几乎没有可能在众多供应商之间实现互操作性。一个平台服务实际上就是一个虚拟设备，如果提供这样设施的每一家供应商都采用了不同的接口，那么问题就大条了，因为你必须在供应商中做出选择或者采用多个供应商。

　　这里有一些步骤可以降低与平台服务非标准API相关的风险。一个就是创建一个单一的应用程序组件来运行，以替代在整个应用程序中的发散。这样一来，如果你选择了一个新的供应商，那么你只需要更换一个组件。另一个策略就是在所有可能的供应商中寻找可替代的服务实施，然后根据广泛的使用约定开发你自己所谓的预包装应用程序。这种方法可以让你在更换供应商时只需做出较少的变化即可。

　　在目前竞争激烈的云计算市场中很可能会出现一个平台服务产品的总体框架，但是应该不可能出现标准。认识到平台服务是把你捆绑在一小撮云计算供应商战车上的强大工具这一点始终是非常重要的，而且你将需要在有限范围云计算产品所带来的风险与平台服务的优势之间做出权衡抉择。