Serverless 不是沒有伺服器，是你不用管伺服器。聽起來像是甲方的夢想對吧？但跟所有「聽起來很美」的東西一樣，魔鬼在細節裡。
先講結論
Serverless 最適合「流量不穩定、邏輯簡單、不需要長時間跑」的場景。如果你的服務是穩定高流量的 API，Serverless 反而可能比一台長駐的容器還貴。它不是萬靈丹，它是一把好用但挑場合的瑞士刀。
到底什麼時候該用？
我自己的判斷標準很簡單：如果這個東西閒著的時間比忙的時間多，就該考慮 Serverless。
典型場景：
- 圖片上傳後自動縮圖——你不會為了偶爾的上傳養一台 server
- Webhook 觸發資料同步——事件來了才跑，沒事就睡
- 排程報表——每天凌晨跑一次，其他 23 小時都在燒錢？
- 小型 API——流量低到不值得開一台 EC2
反過來說，如果你的服務需要跑超過 15 分鐘、需要低延遲的即時連線、或者流量穩定且大，那就別硬套 Serverless，老老實實用容器吧。
Cold Start：Serverless 最痛的地方
每次我跟人介紹 Serverless，第一個被問的問題一定是 cold start。
所謂 cold start，就是你的 function 閒置太久被回收之後，下一次請求進來要重新啟動容器、載入依賴、初始化 runtime。這個過程短則幾十毫秒，長則好幾秒。
對策其實也不複雜，但需要紀律：
// 保持函式輕量，不要塞一堆巨大依賴
// 能 lazy load 就 lazy load
export const handler = async (event) => {
const body = JSON.parse(event.body || '{}')
return {
statusCode: 200,
body: JSON.stringify({ ok: true, id: body.id }),
}
}- 減少套件大小——你真的需要整個 lodash 嗎？
- 用 provisioned concurrency 預熱——花錢買延遲
- 別在初始化階段做 DB 連線以外的重事
試過在 Lambda 裡跑機器學習模型，cold start 十幾秒，使用者都以為網站掛了。
Function 設計的四個紀律
寫 Serverless function 跟寫一般 API 最大的差別是：你的 function 隨時會被殺掉重來。所以：
單一職責——一個 function 只做一件事。想塞多個 endpoint？用 API Gateway 路由，別在 function 裡面自己 switch case。
無狀態——不要依賴本地檔案或記憶體。上一次的執行環境可能已經被回收了。狀態丟回 Redis、DB 或 S3。
短執行——盡量壓在 5-10 秒內。超過的任務拆成多段用 Queue 串起來。
可重試——冪等性不是 nice to have，是必須。因為平台可能會重送事件，你的 function 如果沒有冪等設計，就會產生重複資料。
成本模型：便宜到貴的交叉點
Serverless 的計費邏輯是「用多少付多少」。閒置時幾乎不花錢，這對低流量服務來說太香了。
但你有沒有算過高流量的情況？
假設一個 Lambda function 每月被呼叫 1000 萬次，每次跑 200ms，128MB 記憶體。這筆帳算下來，可能比一台 t3.small 跑整個月還貴。
所以你一定要做成本試算。 找出流量與成本的交叉點，在那個點之前用 Serverless，過了那個點就該考慮長駐服務。
IaC 管理：Serverless 不代表可以手動配
你以為不用管 server 就可以在 console 上點點點？別鬧了。觸發器、權限、環境變數、版本部署，這些東西一樣要用 IaC 管理。
resource "aws_lambda_function" "api" {
function_name = "order-api"
runtime = "nodejs20.x"
handler = "index.handler"
filename = "dist.zip"
memory_size = 512
timeout = 10
}用 Terraform 或 SAM 把所有配置寫成 code，commit 進 repo，才不會出現「staging 跟 prod 的觸發器設定不一樣但沒人知道」這種鬼故事。
延伸閱讀
Serverless 最大的謊言是「不用管伺服器」。你只是把管伺服器的責任外包給了雲端，然後多了一堆新的東西要管。