本文延續 SaaS 篇的雲端簡史，接續探討 PaaS (Platform as a Service) 的歷史，並解釋：「為何絕大多數組織企業目前沒有能力接受 PaaS 的好處？」

最早的 PaaS，可能是出現在 1976 年前後網路協定文件 RFC 707 裡面的 remote procedure call 概念。筆者學生時代較流行的實作，是 Sun RPC。SaaS 篇裡面所談到的 NFS 網路檔案系統應用，就是用 Sun RPC 開發出來的。1990 年代中期的 Microsoft RPC/DCOM 延續這條線，但太複雜，且一開始並不開放，所以最後走入死巷。反而是從頭就開放的 Sun RPC，後來改名為 ONC RPC，現在還有人在用它來開發－主要用處是將過去陳年的 RPC 應用軟體搬到新的環境。
第二波廣泛流行的 PaaS，是始於 1998 年的 XML-RPC。當時 http 已經成形，UserLand Software 與微軟合作設計這個開放的協訂。後來演進成 SOAP (Simple Object Access Protocol)。

但是 SOAP 過於複雜，於是在 2000 左右，出現了 REST (Representational State Transfer) 類型的 PaaS web services。與其說它是一個標準，不如說它是一個設計風格。REST 的設計風格，採用既有的 http 1.0/http 1.1 協定，而不訴諸複雜的 XML 內文定義，以簡單的網址 (URL)「呼叫」或「取用」遠端的資源。從一些分析看來（2005 年文章、2009 年文章、google 宣佈其搜尋引擎介面捨 SOAP 就 REST）REST 逐漸取代 SOAP，成為 PaaS 的主流。這與 "small pieces loosely joined" 小小片、鬆鬆接的網路演化趨勢，可能有關。

一個 PaaS 單獨使用，通常看不太出 PaaS 的明顯好處。對於終端用戶而言，SaaS 才是終極目標、才具有最直接的使用價值；但是某一個 PaaS 若有可能的熱門應用，大約早就有人（可能很多組人馬）做出相對應的免費 SaaS 實作了，又何必自己購買複雜的 PaaS 服務再自己找程式設計師辛苦撰寫？真正有趣、特殊、可以考慮投資人力與金錢的 PaaS 應用，經常來自於同時混搭 (mashup) 採用來自兩個或兩個以上 PaaS 網站的服務。（一個簡單的範例：混搭 google 地圖與行事曆） ProgrammableWeb 這個站的列表與矩陣，搜集了許多提供 PaaS 的網站，以及兩兩組合的應用範例網站。從 way back machine 可以查出來：此站建立於 2005 年 10 月左右。從一個 26x26 的矩陣，成長到今日兩千多個 PaaS 服務、五千多個混搭，這是每一位 PaaS 程式設計師都應該要知道的網站。（當然，那時候還沒有 PaaS 這個名詞。）再以其中的一行（或一列）為例，Google Maps Mania 專門報導 google 地圖與其他 PaaS 的混搭，這也是 PaaS 程式設計師需要知道的重要網站。


談完歷史，再來提一些主觀的建議。

絕大多數中小企業，並不需要 PaaS。
採購 PaaS 就像是採購生食，還需要有專職的廚師將它調理成終端用戶能夠操作的 SaaS。對於絕大多數中小企業而言，直接選用現成的 SaaS（例如 wiki 或 google doc）比較省錢省事。

可能可以受惠於 PaaS 的組織企業當中，絕大多數沒有能力改變工作文化、導入 PaaS。
舉一個最簡單的 PaaS 的例子：混搭訂閱多個 rss。這對於學校很有用：各個處室自己盡管公佈新聞；混搭之後可以放在學校首頁。它屬於最簡單的 REST 類型 PaaS，程式碼超短。如果處室用部落格取代既有的複雜「公告資訊系統」，並善用標籤，甚至還可以推出「訂閱混搭過的標籤」的服務－例如學生可能對全校所有處室科系含有「工讀」機會的混搭標籤，會很有興趣。但是過往一、二十年「中央極權」、「緊密整合」、「與『小小片，鬆鬆接』的網路趨勢完全背道而馳」的資訊系統文化習慣，讓這樣的建議在既有的行政體系底下變得幾乎不可行。

有能力改變工作文化、導入 PaaS 的組織企業當中，絕大多數的場合會站在用戶端（呼叫端）的位置。
例如先前 google 地圖與行事曆混搭的例子，我就是站在用戶端（呼叫端）的位置。此外，要進行這種混搭，組織內需要有某種程度的程式設計人員。而且，最好盡量採用列入 ProgrammableWeb 的成熟、熱門、公開的 PaaS，比較有長遠的保障。

可能可以受惠於 _伺服端_ PaaS 的組織企業，不需要購買 PaaS 工具。
這些組織企業，應該要有工程師群，他們對於雲端技術及 REST 風格的熟悉程度遠超過筆者。如果現成的雲端工具（例如 Apache 的 hadoop）不合用，自行替現成的雲端工具開發模組，遠比採購冷門的專屬 PaaS 更有保障－有國際的開發社群可以互相切磋。附帶一提：什麼樣的組織企業，才會需要 _伺服端_ PaaS？如果組織本身之外，沒有其他人使用你所提供的 PaaS 服務，那麼可能要檢討：這個工作是否根本用現成的 SaaS 自由軟體就可以解決？真正有意義的 _伺服端_ PaaS，應該要能夠被列入 ProgrammableWeb。不過，一旦被列入，而且真的吸引到外部的用戶端（呼叫端）使用者， 那又代表什麼呢？請記得：這裡的每一位「用戶端（呼叫端）」，本身都是一個網站，都在一個網頁伺服器上執行。也就是說，你的用戶，會有很多用戶！這有兩個推論，第一：對於這樣的組織企業來說，行銷／曝光率會是分享 PaaS 的一個很大的收穫。第二：不是很多組織企業有能力做到這一點。Plurk、Twitter 所提供的 PaaS，可以嵌在網頁上，他們就屬於這一類的例子。當貴組織真的能做到這一步，相信您對於注意力經濟的了解程度，早就己經超越筆者，也早就不需要讀筆者「破除雲端炒作」的文章了。

所以，最後一句話還是：想導入雲端？請先從最簡單的「wiki 部分取代 office」這個免費、自主、投資最小、效益最大的 SaaS 私有雲開始實驗，把大部分的資源投入行政文化改造，循序漸進比較實際吧！

您也許有興趣閱讀以下文章:

• （商業炒作之前的）雲端簡史－SaaS 篇 - 2010-10-28