Serverless & FaaS

順帶一提 SaaS, PaaS & IaaS

很久很久以前(大約 13 年前),「雲端運算」(cloud computing) 這個詞開始逐漸被使用並且蓬勃發展,很多相應的服務就此產生,被稱為 XaaS(X as a Service,X 可以以任何字替換)。 SaaS, PaaS 與 IaaS 是傳統三種分類方式,分別代表了軟體即服務(Software as a Service),平台即服務(Platform as a Service),與基礎架構及服務(Infrastructure as a Service)。沒有實際使用經驗的人(e.g. 半年前的我)一開始可能會有點難理解這些服務的差異,不過有很多很棒的平台寫文章介紹,比如 iThomeProgressBar,推薦還不理解直接讀一讀。下面就不錦上添花,直接放一張以車為例子的示意圖。

https://www.k3syspro.com/cloud-computing-choosing-right-deployment-method/

簡單地說,現在各式各樣的應用程式(Gmail, 手機 app 等等)都是屬於 SaaS 軟體服務的範疇,而一個開發人員如果想要部署自己的程式碼,通常會選擇使用 PaaS 平台服務或是 IaaS 基礎建設服務。

好了,不負責任的 Serverless 簡單背景介紹結束,下面進入正題。

Serverless 與 FaaS

一般而言,工程師可以簡單分成開發(Development)跟維運(Operation)兩類。開發工程師負責實現商業邏輯,也就是撰寫程式碼,維運工程師則負責管理程式碼的基礎架構(伺服器、資料庫等),讓程式碼可以順利運行。

雖然現在許多企業都已經採用上面介紹的 IaaS,將網站基礎建設放到雲端,維運的負擔卻沒有減輕很多,還是必須處理資安問題、監控系統等等。

Serverless 是最近發展出來的概念,由 Amazon 在 2014 年發布的 Amazon Lambda 開先鋒,其他科技龍頭也在之後陸續推出相似的服務,像是 Google Cloud FunctionsIBM Cloud FunctionsAzure Functions

這項技術的目的並不是為了實現真正意義上的「無服務器」,而是指由第三方雲計算供應商負責後端基礎結構的維護,以服務的方式為開發者提供所需功能,例如數據庫、消息,以及身份驗證等。簡單地說,這個架構就是要讓開發人員專注代碼的運行而不需要管理任何的基礎設施。程序代碼被部署在諸如 AWS Lambda 這樣的平台上,通過事件驅動的方式去觸發對函數的調用。

節錄自 從 IaaS 到 FaaS— Serverless 架構的前世今生

Serverless 開發的一個好處是「用程式碼來控制程式碼」,也就是 Infrastructure as Code,以往維運工程師可能會是手動去介面調整參數,現在當這些工作變成程式碼,就可以享有很多好處,包含版本控制與 CI/CD(持續整合/持續部署)的流程。

那 FaaS 又是什麼呢?FaaS 的全名是「Function as a Service」(函式即服務),是 Serverless 實現的方式:

Serverless applications are event-driven cloud-based systems where application development rely solely on a combination of third-party services, client-side logic and cloud-hosted remote procedure calls (Functions as a Service).

節錄自 Hackernoon

從上可以看出幾個重點:Serverless 是「事件驅動」(event-driven),由第三方服務(third-party services)、客戶端邏輯(client-side logic)與在雲端上的遠端程序呼叫(cloud-hosted remote procedure calls)所組成。這第三個組成的元素就是 FaaS。

FaaS 的幾個特性

就是個函式(independent, sever-side, logical functions)

名如其實,functions 就如同我們會在程式碼裡面寫的 functions,獨立、分離、自成一格。

無狀態(stateless)

每個請求都是獨立的。每次執行不會受到之前的執行內容/結果影響。任兩次對同一個 function 的呼叫可能會可能會在完全不同的容器(container)裡面執行。

來得很快,去得也快(ephemeral)

FaaS 隨叫隨開,並且做完了任務就馬上關掉,需要的啟動時間與關機時間都非常的短(尺度是毫秒)。

事件驅動(event-triggered)

雖然 functions 可以直接被取用,它們通常會從其他雲端服務被觸發,像是 HTTP 請求或是內部訊息通知。FaaS 比較常被使用的情境是雲端環境中各服務之間的橋樑。

擴展性高(scalable by default)

你可以一次啟動好幾個 container 來同時呼叫同一個 function。就算同意時間有很多的請求(incoming request)也不怕。

Serverless 的優點與缺點

從企業的角度來看

Serverless 最大的優勢就是降低成本,這篇文讓我們看到可口可樂因此省了多少錢。Serverless 可以真的做到「按件計酬」—當沒有使用的時候就沒有花費,這也是它跟 PaaS 最大的不同之處,因為 PaaS 不會因為一個事件而開啟整個應用程序又結束,但是 FaaS 可以做到。不過,如果你的應用程式結構複雜並且會長時間運行,那麼使用 Serverless 不會幫你省到什麼費用。 Serverless 最適合的情境是是不固定、落差大的需求量(spiky demands)。

Serverless 省錢方便的好處也有它的犧牲,由於許多工作都交給了第三方管理,所以企業對產品整體的控制權會減弱,也會有安全性、災後回復的風險。

從開發人員的角度來看

Serverless 可以將維運的負擔降到最低(比如說,不需要為不同的環境設定不同的機器),並且它與 Nanoservices, Microservices, SOA (Service-Oriented Architecture) 的概念是天作之合。同時,由於 FaaS 的高伸縮性,同時併發的請求們(concurrent requests)再也不是難題。

然而,由於 Serverless 還算是一個新的技術,再缺乏有經驗的人的引導之下,可能會導致個元件的碎片化(component fragmentation)、增加整以架構的複雜程度(complex ≠ complicated)還有增加測試的困難。

Serverless 也不是適合所有的架構。當你的應用程式依賴了很多第三方套件(3rd Party Dependencies),那麼表示當你打包這個應用程式時,它會變得很巨大,就不能發揮 FaaS 輕便簡潔的優勢了。

Serverless 是目前還正在如火如荼發展的技術,許多相關的配套與功能也都漸漸成熟。市面上也有出現了像是 Apex 讓你更輕鬆部署 AWS Lambda 的工具,看著看著實在很手癢,希望哪一天真的有實際使用到的機會。

雖然已盡能力所及地確保資料的正確性,但我恐怕還是會有不對/不精確的觀念或用字,如果願意指正我的話我會非常感激!

Random Gems 一些不太相關的資源

最近找資料的時候突然發現這個 free-for-dev 網站,裡面羅列了各種有提供免費服務的平台,並且持續更新中,很完整,很貼心。

還有順便看到這篇 導入 Configuration as code,完成三位一體,裡面將一個分成 infrastructure, code , configuration 三個部分,並探討如何將三個元素都程序化,存參存參。

參考資源

What is Serverless Architecture? What are its Pros and Cons?
hackernoon.com
serverless/examples
github.com

无服务器架构(Serverless Architectures)amio.github.io

文章同步發表於 Medium


  • Find me at