Login  |  繁體中文
感謝您對「自由軟體鑄造場」的支持與愛護,十多年來「自由軟體鑄造場」受中央研究院支持,並在資訊科學研究所以及資訊科技創新研究中心執行,現已完成階段性的任務。 原網站預計持續維運至 2021年底,網站內容基本上不會再更動。本網站由 Denny Huang 備份封存。
也紀念我們永遠的朋友 李士傑先生(Shih-Chieh Ilya Li)。
FOSS Forum (商業炒作之前的)雲端簡史-PaaS 篇

(商業炒作之前的)雲端簡史-PaaS 篇


◎ 本篇文章傳達筆者意見,不代表自由軟體鑄造場電子報立場,回覆意見請見部落格原文網址:https://blog.ofset.org/ckhung/index.php?post/10ad

本文延續 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 私有雲開始實驗,把大部分的資源投入行政文化改造,循序漸進比較實際吧!

You may be interested in the following articles:




OSSF Newsletter : 第 162 期 自由軟體專案授權方式的轉換(上):不得撤銷原授權條款

Category: FOSS Forum