PaaS是继SOA后的自然产物

以前写过一个关于 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 功能的相关讨论，已经出现了。