PaaS平台格局分析：目前有哪些选择？-paas平台

鉴于Salesforce.com近期在Dreamforce大会及其他活动上频频宣布相关内容，现在该好好打量一下平台即服务(PaaS)格局了。对于希望构建随时可以运行的云应用程序的开发人员和企业人员来说，今天平台即服务(PaaS)方面有哪些选择?本文评述了PaaS的格局。

避免被提供商锁定

今年早些时候，我高度赞扬VMware与Salesforce.com共同发布的VMforce.com“一改Salesforce.com迄今为止完全专有的Force.com平台战略。”Heroku架构加入到Force.com大家族证实了这个新的战略方向，对Salesforce.com本身来说是这样，对整个PaaS行业来说也是这样。我早在去年4月份就写道：

“VMforce.com之于SpringSource，就好比Heroku之于Ruby on Rails;它是开源平台的高质量、多租户的操作实例。这种平台之所以备受开发人员的欢迎，原因在于明显不会被提供商锁定。理论上，你总是可以选择换成另一家提供商或内部系统。而实际上，事情可能没有这么容易;但是用户能自行选择很重要。因而，Salesforce.com一下子向主流市场开放了其专有平台……”

“VMforce.com现在重新定义了PaaS格局，而且预示着Salesforce.com自己的PaaS战略会有巨大转变。这不再是闭源专有平台之间的较量了;现在的较量已转移到了两条新的阵线：相互竞争的开源平台之间(将确定其中谁会成为主流的云平台堆栈);以及相互竞争的运营提供商之间(将确定谁会成为主导性的基础架构框架)。”

瞧瞧短短一年内发生了多么惊人的转变：Force.com已经从一个完全专有的平台，变成了大力支持开源代码和框架。现在开发人员可以自由地利用可随意移植的代码，构建Force.com应用程序;从理论上来说，代码可以从一个PaaS提供商移植到另一个提供商，或者移植到自己的内部基础架构。虽然避免被锁定与其说是现实，还不如说是幻想，但考虑到将操作实例从一个平台转移到另一个平台面临的实际障碍，局势已定：人们更偏爱不是完全属于某一家提供商专有的PaaS标准(随之而来的结果是，竞争使得这类解决方案更便宜了)。一个忠告是，在选择PaaS平台时，你应该总是寻求这种选择：不必完全重新编写应用程序的代码，就能换成另一家提供商，哪怕只是理论上有这种选择。

#p#

功能范围

把PaaS描述为单单一个类别会让人有点误解。PaaS分为好多种，从像Heroku和Windows Azure这些最基本的开发平台，直到诸如NetSuite公司的SuiteCloud之类平台(这种平台包括了专门针对某一种应用程序类型的预制业务对象)，不一而足。这后一类最近一直在发展壮大，目前出现了数量众多的提供商。的确，现在软件即服务(SaaS)提供商几乎无一例外地都有这样的路线图：将应用程序扩大到其他提供商也能扩展的可编程平台上。我最近注意到的例子包括如下：

RightNow公司在去年夏天发布了CX云平台，号称是“第一个专门为客户体验而定制的平台”。该平台吸纳了RightNow的客户服务应用软件的所有要件：知识库、用来与客户交互的各种业务对象以及集成应用编程接口(API)，还允许进行定制，以适应特定的业务流程和垂直行业(如医疗保健业)需求。

远程支持技术厂商NTRGlobal在去年10月份推出了一个模块化的新平台，随带的API让合作伙伴可以将其功能集成到定制的解决方案中。这将PaaS的原理运用于非常狭窄的功能范围。

现在连企业软件巨头SAP也加入到其中，准备提供采用PaaS模式的Business ByDesign解决方案，以便合作伙伴进行定制以及适应垂直领域的需要。

另外当然还有Saleforce.com最初的Force.com，它仍然可供使用，这家厂商更新、更开放的PaaS组件同样可供使用。对于想要按Salesforce.com模式，构建经典的表单和数据库SaaS应用程序的那些用户来说，Force.com是一个非常成熟的、功能丰富的PaaS平台。

也许我们需要一个新的术语(App-PaaS?)来描述应用平台即服务的这个更针对特定功能的一层。开发人员在特定平台的功能约束下从事开发，换来的是迅速将应用产品推向市场的优点，还能够致力于将其专长运用到业务流程层，而不是非得利用更加面向工具包的普通PaaS方案，构建整个应用基础架构。PaaS的这一层对系统集成商、小型独立软件开发商(ISV)和服务于垂直领域市场的解决方案提供商来说尤其具有吸引力。它的确需要用户对平台提供商的信任大大提升——被提供商锁定是致命的，但是对许多用户来说，可以迅速将应用产品投向市场的优点值得作出这样的妥协。

给评估这些平台的人提醒一句：不要仅仅关注自己想要构建的应用程序的纯粹的功能范围，还要考虑底层基础架构的XX即服务功能和平台带宽。我之前就写过文章表明，想成功地交付基于PaaS的切实可行的云应用程序，这些要素至关重要。

#p#

情景应用程序

对于迫切想要用应用程序解决企业当前需求的企业人员来说，还有更多的情景应用程序构建工具可以使用。这包括从混合平台到简单的、不需要编码的、对企业友好的应用程序设计工具等各种工具。上周，我还预测它们会由于database.com而消亡，不过更准确的观点也许是等到次日发布的Siteforce和更新版Appforce，它们在这个领域比面向开发人员的database.com更有影响力。

不管怎样，已经占据和服务这个市场的小厂商觉得，没什么新的东西好让自己担心的。大多数小厂商觉得，自己的平台对普通的企业用户来说更有亲和力，无论是由于更高的易用性、更好的专业化，还是更个性化的支持。

PaaS提供商WorkXpress的总裁兼首席执行官Treff LaPlante说：“我们并不觉得这是与我们竞争的一种工具。请记住，我们绝对致力于开发尽量不需要编程的工具。”

Longjump公司的产品和营销战略主管Derek Cheng持有类似的观点，他表示，要让用户采用Force.com平台并非易事：“ISVforce、Appforce和Siteforce也在以新的品牌名重新推出现有的功能，可能是为了让整个平台更容易被用户所接受。”Longjump的另一个差异化因素就是，它在去年年初推出了可以由第三方部署或企业内部部署的版本。

Caspio公司的总裁兼首席执行官Frank Zamani在电子邮件中说：“我们的核心产品一直是只需点击操作的应用程序构建工具，”他又提到了更专业化的厂商所提供的更周到的支持服务。“不过，当然完全有可能出现这种情况，即将来某个时候，大厂商也会提供应用程序构建工具;大厂商会认识到，这是一个服务非常密集型的行业，而它们通常不是很擅长这方面。”

Zamani还提醒了一点：Salesforce.com像database.com这样的产品能不能够继续保持一向比较高的利润。他写道：“我们认为，基础架构是价格方面压力很大的一种大众化商品。其价值体现在针对特定需求的智能解决方案上。”

#p#

多功能SaaS

在关注database.com这样的云数据库时，要牢记的最后一个考量因素是，有没有可能完全拿掉传统Web应用架构中的某一层。我在听了database.com宣布后，马上给Dreamfactory的首席执行官Eric Rubin发去了一封电子邮件。Dreamfactory公司提供的一款web客户软件可以与任何云数据库进行联系，包括亚马逊SimpleDB、Windows Azure和现在的database.com。

使用基于传统Web应用架构的database.com存在一个问题，那就是数据库与除Force.com基础架构之外的任何地方安装的应用服务器之间存在延迟。WorkXpress的LaPlante指出：“请记住，大多数数据库web服务器连接不只是本地的，但人们常常试图直接在它们之间铺设光纤连接。应将直接的光纤连接换成web连接;我认为将来会看到这种连接会很适合一些应用程序，而另一些应用程序不适合。”

解决这个问题的一个办法是，将应用服务器从整个架构中完全拿掉，而是将所有的应用程序逻辑放在客户端，让客户端直接调用云数据库。除了客户端调用应用服务器造成的延迟外，没有更多的延迟;而且对许多应用程序来说，由于让业务逻辑在客户端上本地执行，因而缩短了响应时间。

【编辑推荐】