【Serverless 應用案例賞析筆記】01. Serverless 架構與 Apache OpenWhisk

投影片封面（圖片來源: 課程講義）

本堂課程作為此系列的準備課程，針對不了解 Serverless 的人，介紹 Serverless 概念、特點以及 Open Source Serverless 平台 Apache OpenWhisk 和基於它實做的企業版本 IBM Functions 的概況。

雲端計算的發展趨勢

在課程一開始先帶我們來回顧雲端計算的發展趨勢。

雲端計算的發展趨勢（圖片來源: 課程講義）

由圖中可以發現架構演變的趨勢，是朝著簡單、便捷與低成本實現商業邏輯（Business Logic）的方向前進。

從最開始裸機的配置與開發；接著進入 IaaS 飛速發展，在這期間以 OpenStack 為代表的社區逐漸的成長，發展出許多的雲端平台公司；到之後發展出以 docker 為代表的 containers，而使得 Kubernetes 和 Mesos 等容器調度工具廣為人知。

docker、Swarm、Kubernetes 和 Mesos

文章中所說的 docker 指的是 docker 技術本身。而一般看到的 Docker、 Kubernetes 與 Mesos 的比較文章，更有可能是比較與 Docker Swarm 比較，三者皆為容器調度工具。

三者較可閱讀：
1. Docker、Kubernetes 和 Apache Mesos 对比中的一些误区
2. 2016年容器技术思考：Docker, Kubernetes, Mesos 将走向何方？

由發展史看可以看出，隨著一系列的發展，對底層的屏蔽是日趨增加。

在裸機的時代，開發人員還需要操心系統的設定與維護；而到了 container 階段，則是已經將執行環境抽離，消除底層系統和基礎架構差異性所帶來的問題。

換句話說，隨著對底層屏蔽的增加，使的開發人員能專注於功能或程式本身的開發設計，加速整個開發流程的推進。

而在最近幾年的技術中，又將粒度再次縮小，提出了所謂的 Function as a Service（FaaS），也就是 Serverless，試圖讓開發人員程從系統、運行環境、軟體相依性等複雜的環境中解脫。

什是 Serverless?

Serverless 是雲端計算 IaaS 、 PaaS 的下一個方向，但這像技術並非實現字面意上的『無伺服器』，而是由第三方雲端計算平台供應商負責後端基礎設施的維護，以服務（aaS）的方式為開發者提供所需功能，例如：認證、授權與資料庫服務等。

簡單地說，這裡所強調的『無伺服器』，指的是我們的程式碼不會明確地被部署在某些特定的軟體或者硬體的伺服器上，不需要在伺服器上持續執行行程以等待 HTTP 請求或 API 調用；是通過某種事件機制來觸發程式碼的執行，此時供應商才會將此服務進行部署。這樣的架構可以讓開發人員更專注程式碼的運行，而不需要分心管理任何的基礎設施。

目前已有有些這樣的服務：由第三方供應，且無須安裝、管理和維護，只在需要的時候使用，並按照使用資源計費。

例如實務上，有些開發人員為了更專注於商業邏輯相關程式碼的開發，會將與商業邏輯邏輯無關的部分委託給第三方，像是上述所提到的認證、授權與資料庫服務等，這些都是 Backend-as-a-Service（BaaS）。

也有的將整個程式運行環境給託管出去的，將開發出來的函式直接放動雲端去當作服務在調用，也就是 Function-as-a-Service（FaaS）。

這兩類型的服務都被稱作 Serverless，也都是雲端計算的發展方向。

這邊整理兩種服務的特性：

Function-as-a-Service（FaaS）
- 片段程式碼，按需執行、按需擴展、無需管理任何基礎設施相關部分。
- 事件驅動行計算。函式被事件觸發或是被 HTTP 請求調用。
Backend-as-a-Service（BaaS）
- 第三方基於 API 的服務，實現應用開發中的基礎功能模塊。
- 這些 API 像服務一樣，自動擴展，無需管理。

兩者都強調：按需執行、按需擴展、無需管理。這樣的模式是將軟體開發中的複雜性全部抽出，給開發人員更多的自由，並降低開發門檻；但從另一方面來說，這是將複雜性全留給雲端計算平台供應商。

Serverless 要點

Serverless 僅是一個概念，目前還沒有一個普遍公認的權威的定義，但此概念所要實現的目標表達就是：

無需管理、按需執行、按需擴展、按使用來計費

P.S. 對於按使用來計費，我有兩種理解，按調用次數或使用資源來收費，不過兩種的核心的使用了才付費，就看平台供應商的計價方式了。

至於所使用究竟是 FaaS 或 BaaS 則是次要的。但若採用的 FaaS ，對於函式還是有些要求：

為事件驅動的調用方式。
函式是無狀態、短暫的、且是有限制的，例如：所需記憶體的限制、執行時間的限制。
另外，因為 FaaS 可被 HTTP 調用，因此 API Gateway 設定也是其中的要點。

另外，講師提到一件事 Serverless 雖然包含了兩種服務概念 FaaS 與 BaaS，不過在講解中多會集中在 FaaS，這點在多數的文章中也是。因為 BaaS 這邊複雜度在提供此服務的開發者那邊，對於我們來說會用就好。因此在提到 Serverless 時大家多著墨在 FaaS 這塊。

感應式水龍頭（圖片來源: Amazon）

課程中講師提到關於水龍頭與計算資源的比喻：

雲端計算的的目標是：期望計算資源如同水資源一樣的便捷，打開就可以享用。

按她的比喻來理解，現行的 VM 或是 containers 像是一般水龍頭，打開後除非主動關閉，不然就會 24 小時運行，即便此時無人使用，但還是會佔用資源。

而 Serverless 則像是使用了感應式水龍頭，手伸出去了，資源才會被調用執行，結束後資源就自動停用。

FaaS 與 PaaS 的比較

在第一次看到 FaaS 的觀念時，覺得它像是更專注提供某種功能的 PaaS，所以查了一下兩者的比較。

在維基百科上提到：

以平台即服務（PaaS）為基礎，無伺服器運算提供一個微型的架構 …

所以可以推測 FaaS 是 PaaS 的上層，但還不到 SaaS。

而在 AWS 的官方博客上，則是有說到些兩者的差異：

啟動和停止
大部分 PaaS 應用無法針對每個請求啟動和停止整個應用，而 FaaS 生來就是為了實現這樣的目的。
縮放能力
兩者在維運方面最大的差異在於縮放能力。對於大部分 PaaS 平台，租戶依然需要考慮縮放，就算將它設置為自動縮放，依然無法在具體請求的層面上進行縮放。但是對於 FaaS 應用，這種問題完全是透明的。

文章比較末端，使用 AWS 雲端架構戰略副總裁 Adrian Cockcroft 給的簡單定義來收尾：

如果你的 PaaS 能夠有效地在 20 毫秒內啟動實例並運行半秒，那麼就可以稱之為 Serverless

最後附上一篇兩者的比較： FaaS、PaaS 和无服务器体系结构的优势

Serverless 架構的優點

快速開發/快速響應
對於使用者來說最重要的是快速響應，因為底層全部被屏蔽了，只需專注商業邏輯的開發，無需煩心操作系統、運行環境、版本相容…等問題。借助 Serverless，或許只需要幾個小時，來完成新的實做邏輯即即可，不用再去重新配置環境。
無限擴展
在 Serverless 架構的中，橫向擴展是完全自動的、有彈性的、且由平台供應商所管理，使用者僅需支付您所需要的計算能力。
『綠色』計算
想想剛剛水龍頭的例子，就可以理解了。
對開發者友好
恩…不用管硬體配置，只要寫程式就好。這對我這個討厭配置環境的人來說，真的是非常友好 XDDD 每次配環境都會在坑裡掙扎超久的 Orz
費用用低
在降低成本上包含了兩個方面，即基礎設施的成本和人員（運營/開發）的成本。

Opensource Serverless 平台 - Apache OpenWhisk

Apache OpenWhisk（圖片來源: CNCF Cloud）

OpenWhisk 是一個開源 FaaS 平台，現在已經脫離孵化器，是 Apache 的一個頂級項目，也在 IBM 公有雲上有做了驗證。它是一個典型的事件驅動型的程式編輯模型。

事件驅動顧名思義就是，事件來了才去做一件事情。以講師給的流程圖為例：
當事件源觸動觸發器後進入系統，然後在系統中通過規則的匹配去決定要觸發的動作，最終產生所需的結果。通常來說，輸入與輸出的的資料格式都是 Json。

Apache OpenWhisk 理念（圖片來源: 課程講義）

在這邊出現了幾個詞，觸發器 (Trigger)、動作 (Action) 與規則 (Rule)，這些詞我跟下一節的筆記整理在一起。

OpenWhisk 程式編輯模型

Apache OpenWhisk 程式編輯模型（圖片來源: 課程講義）

觸發器 (Trigger)

觸發器可以對外界數據源，如資料庫的增刪查改、 github 上的 push、issue…等，進行對應的反應。

不過在 OpenWhisk 中觸發器僅某類別事件的具名頻道，換句話說僅是一個名字。觸發器要對反應特定類型事件的宣告，再藉由使用者或是透過事件來源觸發觸發器。

以資料庫更新為例，若是事件來源觸發，在 OpenWhisk 之外會有一個 Event provider，由它監聽資料庫。當 provider 監聽到更新事件時，再由它通知 Trigger 資料更新了。

Trigger（圖片來源: 課程講義）

動作 (Action)

動作是執行某個特定動作的一段程式碼，它將會在 openwhisk 中執行。使用所選擇的語言來撰寫 Action，或者直接將 Docker 以映像檔提供執行。

Action 中什麼都可以放，諸如：計算、資料格式轉換、資料抽取、第三方 API 調用…等，程式寫的出來的都行。但必須注意的是，在 FaaS 中是無狀態的，不應該存在狀態的紀錄，而且短時運行的。在 openwhisk 中預設最長執行時間為是 5 分鐘，若超過 5 分鐘則不建議使用 Faas 執行，或是必須在要切成更小的粒度分開執行。

Action（圖片來源: 課程講義）

動作序列 / 動作串 (Sequence)

全稱是 Action Sequence，這並不在講師的講義中，僅出現在講解過程中出現。

動作序列顧名思義，就是把一系列的動作鏈結來。它是一串按順序呼叫的動作，其中某個動作的輸出會傳遞為下一個動作的輸入，達到動作重複使用的目的。

規則 (Rule)

規則會建立觸發器與動作（序列）的關聯。每次觸發觸發器時，規則都會使用觸發事件作為輸入，並呼叫關聯的動作（序列）。使用適當的規則集時，單一觸發器事件可能會呼叫多個動作，也可能會呼叫動作以作為多個觸發程式的事件的回應。

Rule（圖片來源: 課程講義）

套件 (Package)

就是一個集合，可能包含 action、trigger、rule…等，可以利用套件來新增與服務及事件提供者的整合。

這邊講師沒多說，不過 IBM 的名詞解釋舉了個例子：

使用 IBM Cloudant 變更資訊來源所建立的觸發程式，會將服務配置成在每次修改文件或將其新增至 IBM Cloudant 資料庫時發動觸發程式。套件中的動作代表服務提供者可設為可用的可重複使用邏輯，如此，開發人員可以使用服務作為事件來源，以及呼叫該服務的 API。

Package （圖片來源: 課程講義）

最後來貼張漂亮的流程圖：

OpenWhisk 流程示例（圖片來源: 課程講義）

Apache OpenWhisk 的部署方式

Apache OpenWhisk 的部署看理來很簡單，只要支援 docker 的設備都可以安裝，Apache 已將相關內容都把包成 docker image。相關配置步驟可以看這兩份官方的說明文件：文件1、文件2

…不過有沒有真的這麼簡單，可能要頭洗下去才知道。

Apache OpenWhisk的部署方式（圖片來源: 課程講義）

IBM Functions

先前提過 OpenWhisk 有在 IBM 公有雲上有做了驗證，所以這邊講師就示範了在公有雲上的簡單操作。

建立 Action

從入口處點選開始建立
選擇建立動作
建立套件
這步驟非必須，這邊只是試著操作。
為動作命名，並引入剛剛所創建的套件
這邊為了測試方便，運行環境直接選擇 Node.js
建立後會出現 Node.js 的程式碼作為動作的執行細節
再依照實際要執行的動作進行修改，完成後可以試著點選呼叫，查看動作執行後的結果。

也可以透過 curl 來呼叫
1
$ curl -u API-KEY -X POST https://us-south.functions.cloud.ibm.com/api/v1/namespaces/id%40dgmail.com/actions/test/hello?blocking=true

建立 Trigger

從入口處點選開始建立
選擇建立觸發程式
設定定時式的觸發器
這邊先簡單設定一個定時觸發的觸發器
設定觸發時間
這邊使用 cron 的方式設定每 20 秒觸發
查看
完成與 action 的連接後，可到監視查看。

應該會看到 trigger 每 20 秒被觸發，接著執行 action 。
P.S. Oops，我現在才發現 every20 打錯了，不過也來不及了…