PaaS是继SOA,SaaS后的自然产物

 以前写过一个关于 Amazon Web Services (AWS) 的帖子,这应该算是第一个对 Web 2.0/ SOA 基础设施租赁市场的大规模尝试。不久前接受采访,起因于微软的 Internet Service Bus,一个小规模、提供给开发者作实验性的尝试。

  我对 AWS 、以及它所试探的潜在市场,基本上乐观其成,自从 AWS 推出 S3, SQS 和 EC2 后,已经出现了许多有趣的加值应用,例如有人用它来建构新一代的 B2B/EDI VAN,Doug Kaye 在这个 podcast 中,则侃侃而谈,说明如何利用 AWS 的基础设施,设计出 GigaVox 这个 podcast 平台的架构。在 podcast 讨论中,Kaye 除了讲解他如何善用 Amazon 出租的数据服务 S3,中介消息服务 SQS,和建立在 Xen 上的虚拟化平台 EC2,来设计出他的应用架构外, 还谈到作为一个 early adopter,所遇到的种种限制问题,如何克服,更提供了 Amazon 未来对 AWS 的改进参考。不意外,就像所有软件一样,这种直接通过网络租用的软件服务,目前仍属于非常早的阶段,当然还有不少可进一步完善的空间。这类的案例,非常有助于我们对此类服务的完备和成熟程度,进行更客观的理解。

  如果从投资/管理的角度,AWS 的确是比较大胆的尝试,所以我之前曾以“豪赌”来形容。我们看它最近的财报,对 AWS 运营的情形,只敢简单提提有几十万的注册开发者,数据库被存了十几亿个对象,但不敢提实际的损益情形。这就像默多克的新闻集团一样,买下了 MySpace,但现在 MySpace 在整个集团的财报中,还只能隐含在“其他杂项收入”中,占非常小的比例,其他的几乎都来自它的本业(传统媒体)收入。但话说回来,许多商场上的一代枭雄,凭藉的不正是快、准、狠的大胆投资气魄吗?而历史上后来大发利市的商业模式,当初也有不少是误打误撞的结果。

  不扯那些了,来谈谈这个新模式本身所代表的意义,这种服务基础设施的租赁,可以视为是 SOA 和 SaaS (Software as a Service) 之后,下一个自然的演化 -- 当位于堆栈上层的应用 (CRM, SFA, ...) 被服务化、租出去之后(即 SaaS),接着下来就是下层的服务基础设施了。Salesforce.com 现在强力主打的 Force.com 平台(稍早曾称为 Salesforce SOA、Apex),正是最好的例子,最近更打出 "Platform as a Service" (PaaS) 的顺口新词。SaaS 现在已经有许多的媒体讨论,不再多提,SAP 最近宣布正式进入这个市场,也让它更加热闹起来。而 PaaS,可以说是进一步把支撑应用的下面几层功能,可以从中间件一直到数据库、还有虚拟化的 OS 环境,也分别通过网络出租出去,通过网络来进行远程开发、配置、部署,最后直接执行在提供 hosting 服务的厂商的计算中心内。

  Salesforce.com 号称,客户不只利用他们的 Force.com 平台做 mashups,集成 Google Map 这类 Web 2.0 网站的 Web services;而更已经有客户,利用它来成功集成了企业防火墙内的 SAP 应用。当租用 SaaS 的那些企业的 IT,对“服务”的概念和实践经验,有了愈来愈深的领悟和掌握后,自然而然将促进企业内更多非租用、自行维护的系统的服务化。所以 SaaS 和 PaaS 的出现,对 SOA 是非常正面的发展。可想而知的是,先期采用 PaaS 模式的企业,绝大多数会是那些现有的 SaaS 客户,他们对于直接通过网络进行远程操作和管理的模式、对效能和可靠性等 RASP (Reliability, Availability, Scalability, & Performance) 方面的顾虑,租用合同相关事宜等方面,都有比较大的信心和比较好的掌握。再者,因为他们已经有某个重要系统 (CRM, SFA, PLM) 是以 SaaS 方式向人租用,很自然地会逐渐有各种业务需求,需要把这些外租的 SaaS 应用和内营的其他应用,如 ERP 等,进行集成。这时候,PaaS 业者会游说:与其你自己花工夫去购买、学习、管理整套 SOA 的基础设施,何不干脆也向我们租用,反正你要集成的主要对象之一 -- 你的 {CRM|SFA|PLM} 系统现在已经跑在我的中心里了,从你内网的集成平台来远程整合我的 {CRM|SFA|PLM},和租用我的集成平台去远程整合你的 ERP 不也差不多吗?而且,你过去在租用我的 {CRM|SFA|PLM} 时,就已经用过我们的开发工具箱了,对我们的开发、配置环境已经很熟悉,你现在可以不需要学习新的语言、工具,便可很快上手使用我的集成平台,何乐而不为?

  从学术的角度,如果拿我们常讲的 SOA 层次化架构(参考架构),堆栈中的各个部件:

  

  来和 Force.com 的架构(如下)相比,会发现很多有趣的相似处。至少在概念上,这些 "XXX as a Service" 中的 XXX,把典型 SOA 中间件所提供的展现层、集成层,和数据服务层的功能,都划进来了。当然,其功能性到底能达到什么程度,还有待检验,但由于模式和设计目标的不同,加上目前仍处于非常前期的阶段,我们不用期待它会有一般 SOA 平台产品中的 portal, ESB, integration server , 数据服务平台等来得那么丰富、强大 -- 实际上可能恰好想反 -- AWS 的 S3 和 SQS 就是很好的例子,由于它们在先天的设计上,必须高度的松耦合;与传统中间件相比,“极简”反而成为它们主要的卖点和价值,这是 S3, SQS 从命名上便想强调的特性 -- Simple(当然,Force.com 相较之下,会比 AWS 来得紧耦合得多,和它既有的应用平台有相当程度的捆绑,因为它当前主要的客户目标,是针对租用它 CRM 应用的客户,通用性上不如 AWS)。此外,与上图相对照,我们看到 Force.com 目前还少了业务流程服务 (BPM) 这层,还有 ESB 也尚未出现,不过将 Intergration-as-a-Service 这层加以延伸,增加 ESB 功能的相关讨论,已经出现了。

 

你可能感兴趣的:(IT业界视点)