各家 Serverless 短評

最近花了點時間比較一下各家 serverless 的特色，雖然我們一直以來都是用 AWS 的服務，但廣泛的瞭解一下其他家的服務也是必要的。

這篇短評涉及的 serverless 包括之前比較流行的 platform as a service 和現在比較流行的 function as a service，這兩種 XaaS 都可以以 serverless 概括稱之，下文會先介紹一下什麼是 serverless 以及這樣的架構對資訊產業帶來的變革，後面再逐一的介紹各家 serverless 服務中我們關注的特點。

Serverless

在 serverless 架構出現之前，一個 app 除了本身的程式與架構有我們自行開發和維護的工作外，還要考慮到主機的軟硬體配置，包括硬體效能和作業系統等等，以及這些事項的後續維護工作等等，後來陸續出現了虛擬機器、應用容器化、雲端服務等架構上的演進，這些演進陸續地把硬體層和作業系統層這些對應用開發來說非核心但卻又不能沒有的部分抽離，交由專業的雲端服務商管理，也就是說我們只要專注於我們的應用本身的開發與維護工作即可，原本實體的硬體變成雲端服務商提供的虛擬化容器，底層作業系統也因為應用被容器化的關係，變成我們無法觸及也不用花心力更新的抽象層，像這樣由雲端服務商提供的免自行管理硬體層與作業系統層的平台架構就稱為 serverless。

這樣分層分工後帶來的優勢是成本和稼動率的優化，對雲端服務商來說，負責底層伺服器主機和作業系統的維護，他們擁有數量龐大的伺服器和機房，規模化的結果就是更低的採購和管理成本和更高的議價和制定規格的能力。應用容器化之後的另一個變革是稼動率的提升，在容器化的管理機制下，應用的水平和垂直擴充成為可以隨負載動態增減的形式，這意味著運算資源調配上的彈性，這樣的彈性也帶來計價模式的彈性，過往以 CPU、記憶體為基礎的計價模式在 serverless 時代變為更精細的以運算次數或運算時間為基礎的計價模式。

對我們來說則是省去自行採購伺服器的金錢和時間，工程人員可以專注於自有應用的開發和維運，不用去管停電、硬碟壞軌、電源供應器爆炸、作業系統升級等瑣碎的工作，人力成本遞減之外，也加快了 time-to-market 的時間，開立一個新專案的時間只要幾十分鐘，不用等機器坐船來、不用裝機器、不用拉線，一切的底層架構都是在雲端服務商的網站上隨點即用，得益於前面講的計價模式彈性化，我們也不再需要高估可能的負載而採購太高貴的機器，或者反過來低估了負載買了太低階的機器，而因此還要花時間擴充機台，這一切都在 serverless 的彈性架構下而不復存在。

然而 serverless 也帶來程式架構轉變的副作用，FaaS 把過往後端的大服務打散成一個個的微服務，因而帶進新的函式生命週期、狀態管理、持久化儲存、訊息交換等的新問題，這些問題雲端服務商也都有搭配的解決方案，但也因此可能落入 vendor lock-in 的養套殺窘境，因此要踏進 serverless 架構前，審慎的評估是重要的，該思考的不僅是技術面與成本面，供應商風險也是必須考量的一部分。

下文分享我們最近對各派 serverless 服務商的重點短評，期望對正在對 serveless 評估的朋友們有點幫助。

Serverless 服務短評

AWS Elastic Beanstalk & AWS Lambda

AWS 是全球最大的雲端廠商，AWS 的 PaaS 服務是 AWS Elastic Beanstalk，Beanstalk 服務需要搭配 EC2 機器使用，它的計價模式為 Beanstalk 服務免費，收費的是 EC2 以及相關的服務費用，也因為是用自己開的 EC2 機器，所以 Beanstalk 並沒有特別的系統資源限制，只要 EC2 開的夠力就能跑任何我們的應用。Beanstalk 支援的語言有 Go、Java、.NET、Node.js、PHP、Python、Ruby，也支援部署容器，所以就算是像 Rust 或 Julia 這些不被原生支援的語言也可以透過容器的方式運行。

AWS 的 FaaS 服務則是 AWS Lambda，Lambda 的計價模式是以函式被請求的次數、運算執行時間、記憶體負載三者為基礎的計費。AWS Lambda 支援的語言有 Node.js、Python、Ruby、Java、Go、C#、PowerShell，Lambda 也支援容器化的應用。系統限制方面，比較要注意的是函式一次最長只能跑 900 秒。

Heroku Dynos

Heroku 應該是 PaaS 領域中最大的廠商，Heroku 的基礎運算與計費單位是 Dynos，Heroku 支援的語言有 Node.js、Ruby、Java、PHP、Python、Go、Scala、Clojure，也支援部署容器。Heroku 比較令人在意的限制有 HTTP 的請求必須在 30 秒內回覆，其餘沒有特別顯著的限制，只差別在不同費率方案給出的功能與資源差異上。

Deta Micros

Deta 是相對小規模的 FaaS 服務商，Deta 支援的語言也僅有 Node.js 12 和 Python 3.7 兩種，Deta 的函式運算時間限制是 10 秒，可以人工要求加到 15 分鐘；記憶體則是 128 MB，也可以人工要求加到 3 GB，Deta 的服務和費率都相對單純，比較適合拿來放玩具，前面提到的人工追加資源的部分應該是要另外收費的，但網站上並沒有追加的費率表。

Vercel Functions

Vercel 是著名 React 框架 Next.js 的開發團隊，Vercel 自己營運前端代管服務也有提供 FaaS 的服務 Vercel Functions，Vercel Functions 目前僅供付費的 Vercel 客戶使用，它支援的語言有 Node.js、Go、Python、Ruby，Vercel Functions 也有運算時間的限制，時間依照費率方案不同而異，最短的只有 10 秒，另外與 Heroku 類似的，請求必須在 30 秒內回覆，否則會引發逾時錯誤。

Netlify Functions

Netlify 是 Vercel 的直接競爭者，Netlify 比 Vercel 大方一點，免費的用戶也可以放 FaaS 函式，但 Netlify 支援的語言僅有 JavaScript 和 Go。Netlify Functions 的運算時間上限是 10 秒，可以人工請求到最大 25 秒，Netlify 有另外一種 background functions 的服務可以跑最長 15 分鐘的函式，但需要每月收費 99 美金的商業方案才有提供。

Cloudflare Workers

Cloudflare Workers 提供的 FaaS 函式與前面其他家較為不同，它是以 Service Worker API 概念下的 FaaS 架構，因此請求是來自 fetch 事件，函式也必須以 Service Worker 的概念下去處理，整套搬 Service Worker 的結果就是它只支援 JavaScript，而且裝其他 NPM 套件必須撰寫額外的配置。

Cloudflare Workers 的限制是函式的 CPU 的運算時間，免費用戶是 10 ms，付費用戶是 50 ms，乍看很少，但這是函式用到 CPU 的運算時間，而其他家的 10 秒是整個函式從請求到回覆的全部時間，計算基礎並不相同，舉例來說，一個函式會再發送請求到某個外部 API 再回覆給客戶端，整個時間為 15 秒，這在 Vercel 和 Netlify 會逾時，但在 Cloudflare 因為真正用到 CPU 的時間只有 1ms 所以反而可以順利跑完。

其他

列出一些漏網之魚：

• Oracle Functions：採用的是開源的 FaaS 方案 Fn Project，實際上應該反過來說，是甲骨文把 Fn Project 開源放送出去的。
• Jelastic：Jelastic 並非供應商，而是供應商的供應商，可以想像成 PaaS 界的 Plesk，主機代管公司買了 Jelastic 就可以瞬間推出 PaaS 的平台。
• 開源 serverless 專案：包括上面提到的 Fn Project 是以 Docker 為基礎的 FaaS 開源專案，還有 Fission 是以 K8s 為基礎的 FaaS 專案。

整理

結語

這裡我們分享了 serverless 架構帶來的成本和效率上的優勢，但 serverless 服務商也有各自的限制，同時 serverless 也讓系統必須以微服務的架構去規劃，另外還要考慮到 vendor lock-in 的問題，這些面向都是導入 serverless 時必須考慮到的點，在做出技術框架的抉擇前都要審慎評估每個面向的優劣，對既有系統來說，漸進式的走向 serverless 是可以考慮的，把既有系統中相對獨立的模組拆分到 serverless 平台上，甚至混合採用各家 serverless 服務也是可能的選擇，只要處理好和前端的 CORS 問題，這不失為評估各家服務的方法，畢竟不論是重構或是遷移的成本都是巨大的，越審慎評估越能避免爾後砍掉重練的可能性，不然也只能安慰自己神仙打鼓有時錯腳步踏錯誰人無了。