白話文解說 Serverless 架構
很久以前被 Serverless 這個 fancy 的詞給唬到，想說是什麼雲端運算黑科技，沒有 Server 還可以提供服務！？ 後來才發現是大誤解⋯⋯。
Serverless 還是需要 Server 提供服務，只是對開發者而言不再需要像傳統開發方式那般經歷以下 4 個階段：
- 開發應用
- 架設伺服器、環境
- 部署應用
- 維運
對使用 Serverless 架構的開發者而言，簡化為只需要 1 步：
「開發應用」
剩下都由雲端運算的服務提供商幫忙搞定，所以 Serverless 解決方案(AWS lambda, Google Cloud Functions 等等)都是讓開發者上傳程式碼而已，剩下的伺服器架設、部署、維運都是雲端運算服務提供商負責，使用費用也相對低廉，用多少算多少，而且多數每個月都有免費額度可以使用，只要在額度內可以蹭免錢的 A_A
其實它就像是 1 個 API 端點，只是它只在雲端服務提供商那端收到 HTTP requests 或者被事件觸發時，才會特別把你的程式招喚出來提供服務，如果處於閒置狀態的話，運算資源就會被回收，讓你的程式再次進入休眠狀態，所以它會有稍微高一點的 latency 問題（因為喚醒執行環境與執行程式需要時間，專業術語稱為 Cold Start / 冷啟動），如果你的服務對 latency 很要求，最好別用 Serverless……。
Serverless 架構對於新創或者預算抓很緊的公司來說，絕對是需要納入考量的架構，建議可以把一些非核心的功能放到 Serverless 架構，減少租用額外伺服器的需要，將資金花在刀口上。
Serverless 架構適合應用在：
- Web 後端，建議非核心業務，例如把核心結帳功能用 Serverless 架構應該會很頭痛，但像是訂閱電子報、文章留言就很適合交給 Serverless 架構
- Event-driven processing, 這種有事件觸發才執行的工作，特別適合 Serverless 架構，例如收到付款成功事件後觸發列印發票的功能，可以省去架伺服器常駐等監聽事件被觸發的情況
- Cron jobs 以及 ETL pipelines, 這 2 種應用情境，都是對於 latency 要求相對小的情境，畢竟對於動輒要執行個好幾秒到數十分鐘的工作而言，幾百 ms 的延遲真的不算什麼
不過 Severless 並沒有 1 個標準，所以每個雲端運算服務提供商的規定都不太一樣，這會導致 Serverless 無法無縫轉換雲端服務提供商，做些修改都是勢必的⋯⋯。
以上！
