PaaS 是繼 SOA, SaaS 後的自然產物

以前寫過一個關於 Amazon Web Services (AWS) 的文章，這應該算是第一個對 Web 2.0／SOA 基礎設施租賃市場的大規模嘗試。不久前接受 iTHome 採訪，起因於微軟的 Internet Service Bus，一個小規模、提供給開發人員作實驗性的嘗試。

我對 AWS 、以及它所試探的潛在市場，基本上樂觀其成，自從 AWS 推出 S3, SQS 和 EC2 後，已經出現了許多有趣的加值應用，例如有人用它來建構新一代的 B2B/EDI VAN，Doug Kaye 在這個 podcast 中，則侃侃而談，說明如何利用 AWS 的基礎設施，設計出 GigaVox 這個 podcast 平台的架構。在 podcast 討論中，Kaye 除了講解他如何善用 Amazon 出租的資料服務 S3，中介Message Service 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 功能的相關討論，已經出現了。