「資訊.人.權.貴 隨便記」 庫存頁面

最早的 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)。 這一波的 PaaS, 有時也稱為 Web Services。

但是 SOAP 過於複雜 (ㄟ, 有沒有注意到微軟所設計的東西的特性啊 :D 跟組織文化也許有關吧), 而且有一些設計趨勢讓原本 stateless (不需要記憶用戶狀態) 的伺服器背起過度的責任 (對每一位用戶, 必須記得他目前的狀態), 於是在 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" 小小片, 鬆鬆接 的網路演化趨勢, 可能有關。 與 REST 設計風格最搭配的技術, 則是 AJAX -- google maps 正是一個最明顯的例子。

一個 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 程式設計師需要知道的重要網站。

[2011/05/09 補充] 有鑑於各家的 PaaS 界面各不相同, 學習起來浪費時間精力, Yahoo! 推出 Yahoo! Query Language (YQL) 讓開發者可以用簡單的 「類似 SQL 指令」 這種統一的界面使用許多不同 PaaS 網站所提供的服務。

* * * * *

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

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

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

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

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

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

* * * * *