軟體SaaS 演變：為什麼無伺服器
SaaS 之所以能夠提供遠低於傳統授權的單位價格，核心關鍵在於「多租戶架構」（Multi-tenancy）。簡單來說，就是讓多個客戶共用同一套執行環境與資料庫，透過邏輯隔離而非實體隔離來區分資料。這樣的設計把固定成本攤提到大量客戶身上，讓邊際成本趨近於零，也讓軟體公司能夠用訂閱制持續收費。
但多租戶架構同時也帶來新的工程挑戰：單一客戶的流量尖峰可能影響其他租戶；資料隔離一旦出錯就是嚴重的資安事件；版本升級必須在不中斷服務的前提下完成。這些挑戰在傳統單租戶架構中並不存在，卻是 SaaS 供應商的日常。也正是在這樣的壓力下，「如何用更彈性、更自動化的方式管理執行環境」成為 SaaS 架構演進的主旋律，而這正是無伺服器登場的舞台。
二、無伺服器是什麼？拆解 Serverless 的真實樣貌
「無伺服器」這個詞很容易讓人誤會，彷彿伺服器真的消失了。實際上伺服器仍然存在，只是使用者不再需要直接管理它們。這個名詞最早在 2012 年左右被提出，但真正讓它普及的，是 2014 年 AWS Lambda 的推出。從那之後，Serverless 逐漸從一個邊緣概念，變成雲端架構的主流選項之一。
2.1 FaaS 與 BaaS：無伺服器的兩大支柱
業界通常把無伺服器拆成兩個部分來理解：
這兩者經常一起出現，因為它們共享同一個核心精神：把「執行環境的管理責任」從開發者手上轉移到雲端供應商。開發者只需要描述「要做什麼」，而不是「要怎麼把伺服器準備好」。
2.2 無伺服器與容器、虛擬機的差異
為了更清楚理解無伺服器的定位，可以把它與虛擬機、容器做一個對照：
換句話說，這三者不是「誰取代誰」的關係，而是「抽象層級不同」的關係。團隊可以根據應用特性，在不同區塊選用不同層級：核心交易系統可能仍需要容器或 VM 來精細控制，但周邊的事件處理、圖片壓縮、報表產生、Webhook 接收等任務，就很適合交給無伺服器。
2.3 常見誤解：無伺服器不是「沒有伺服器」
在實務諮詢中，最常出現的誤解有三個：
第一，認為無伺服器等於「不用管架構」。 事實上，無伺服器只是把「伺服器維運」自動化，應用層的架構設計仍然存在，甚至因為函式粒度更細，分散式系統的複雜度反而更明顯。開發者仍然要思考資料一致性、錯誤重試、逾時處理、幂等性設計等問題。
第二，認為無伺服器一定比較便宜。 這是最危險的誤解。無伺服器的計費模式是「按執行時間與請求次數」，對於穩定高流量的工作負載，長期下來可能比預留資源的容器或 VM 更貴。成本優勢通常出現在「間歇性、突發性、低頻」的工作負載上。
第三，認為無伺服器不適合正式環境。 早期確實有冷啟動、執行時間上限、記憶體限制等問題，但隨著平台成熟，這些限制已經大幅放寬。今天許多大型 SaaS 產品已經把無伺服器用在核心流程上，只是通常會搭配快取、預熱與混合架構來避開極端情況。
三、為什麼 SaaS 擁抱無伺服器？五大驅動力
理解了無伺服器的本質之後，就可以回到本文的核心問題：為什麼 SaaS 產品會擁抱無伺服器？答案可以歸納為五個驅動力，這五個驅動力彼此扣連，共同構成了 SaaS 架構演進的內在邏輯。
3.1 成本結構從固定資本支出轉為變動營運支出
傳統 SaaS 供應商在架構底層時，通常要預先估算容量，然後購買或租用一批固定的伺服器資源。這些資源在離峰時段仍然是閒置的，形成所謂的「容量緩衝成本」。對於成長期的新創來說，這筆成本往往吃掉大量現金流；對於成熟企業來說，則是長期效率的損失。
無伺服器把成本結構徹底翻轉：沒有請求就沒有費用，有請求才按實際用量計費。這對 SaaS 產品特別有吸引力，因為 SaaS 的流量特徵經常是「平日白天高、週末低；月初高、月底低；行銷活動期間暴衝」。這種不規則的流量曲線，正好是無伺服器計費模式的甜蜜點。團隊可以把省下來的固定成本，轉投入到產品研發與客戶成功上，形成更健康的成長循環。
當然，這並不代表無伺服器永遠便宜。實務上常見的做法是「混合計費策略」：把穩定基載流量放在預留資源上，把突發流量交給無伺服器，再用成本監控工具持續優化。這種「基載 + 彈性」的組合，往往是成本與穩定性的最佳平衡點。
3.2 自動擴展與流量尖峰的從容應對
SaaS 產品最怕的場景之一，就是「爆紅」。一場成功的行銷活動、一則被轉發的社群貼文、一次媒體報導，都可能在幾分鐘內帶來十倍甚至百倍的流量。傳統架構面對這種情況，通常需要預先擴容、設定自動擴展規則，甚至手動介入，整個過程充滿不確定性。
無伺服器的自動擴展是「內建」的。平台會根據實際請求量，自動啟動對應數量的執行實例，使用者不需要設定任何擴展規則。這對 SaaS 團隊的意義不只是「省事」，而是「風險轉移」：把流量尖峰的處理責任，從內部工程團隊轉移到雲端供應商的基礎設施上。團隊可以更專注在產品功能與客戶體驗，而不是在半夜盯著監控儀表板祈禱。
不過，自動擴展也不是萬靈丹。下游資源（例如資料庫連線數、第三方 API 速率限制）仍然是瓶頸，因此無伺服器架構通常會搭配佇列、快取與節流機制，避免「前端無限擴展、後端瞬間崩潰」的窘境。
3.3 維運負擔的轉移與團隊專注力
對多數 SaaS 團隊而言，工程師的時間是最稀缺的資源。傳統架構下，團隊必須花大量時間在作業系統修補、容器叢集升級、負載平衡器設定、憑證更新、日誌收集、監控告警等維運工作上。這些工作不是不重要，但它們不直接創造產品差異化。
無伺服器把這些工作大幅自動化，讓團隊可以把注意力集中在「業務邏輯」與「使用者價值」上。這對小型團隊尤其關鍵：一個五人的新創團隊，如果還要負責管理 Kubernetes 叢集，幾乎不可能同時維持產品迭代速度。無伺服器讓他們可以用「小團隊、大槓桿」的方式運作，這是 SaaS 生態能夠蓬勃發展的重要基礎。
當然，維運負擔並沒有完全消失，只是轉移了。團隊仍然需要關注可觀測性、成本監控、安全性與架構治理，只是這些工作的形式從「操作伺服器」變成「設定與分析」。
3.4 上市速度與實驗迭代
SaaS 產品的成功，往往取決於「迭代速度」。誰能更快驗證假設、更快推出功能、更快修正錯誤，誰就更有機會在市場上勝出。無伺服器在這方面有明顯優勢：開發者不需要等待基礎設施申請、不需要設定部署管線、不需要協調維運窗口，只要把程式碼上傳，就能立刻執行。
這種「低摩擦」的開發體驗，讓團隊可以用更小的批次進行實驗。例如，一個新的 Webhook 接收端點、一個圖片壓縮流程、一個報表匯出功能，都可以用單一函式快速實作，驗證有效之後再決定是否投入更多資源重構。這種「先求有、再求好」的節奏，正是現代 SaaS 產品迭代的常態。
3.5 安全性與合規的規模化
安全性經常被認為是無伺服器的弱點，但從另一個角度來看，它其實是優勢。雲端供應商投入大量資源在實體安全、網路隔離、身分驗證、加密金鑰管理與合規認證上，這些能力對個別 SaaS 團隊來說，幾乎不可能獨力達到同等水準。
無伺服器架構通常預設搭配 IAM（身分與存取管理）、VPC（虛擬私有雲）、KMS（金鑰管理服務）等機制，讓團隊可以用「最小權限原則」來設計每個函式的存取範圍。這種「以函式為單位」的權限粒度，比傳統「以伺服器為單位」的權限模型更精細，也更容易實施縱深防禦。
當然，合規仍然是團隊自己的責任。無伺服器不會自動讓產品符合 GDPR、HIPAA 或 PCI DSS，團隊仍然需要設計資料流、記錄稽核軌跡、管理個資刪除流程。但至少底層基礎設施的合規性，可以站在供應商的肩膀上。
四、SaaS 導入無伺服器的實務評測
談完了驅動力，接下來要進入比較務實的層面。無伺服器不是萬靈丹，它在某些場景表現出色，在另一些場景則可能帶來反效果。以下從適用性、挑戰與治理三個角度進行評測。
4.1 適用場景與不適用場景
根據實務經驗，以下幾類工作負載特別適合無伺服器：
相對地，以下場景則需要謹慎評估：
4.2 冷啟動、供應商鎖定與可觀測性三大挑戰
無伺服器在實務上最常被討論的三個挑戰，分別是冷啟動、供應商鎖定與可觀測性。
冷啟動（Cold Start） 指的是函式在一段時間未被呼叫後，平台需要重新啟動執行環境，導致第一次請求的延遲明顯增加。這個問題在 Java、.NET 等需要啟動虛擬機的語言上特別明顯，在 Node.js、Python、Go 等輕量執行環境上則相對輕微。實務上的緩解方式包括：使用預熱機制、選擇支援「預留並行」的平台、把函式拆得更小、把初始化工作移到全域變數等。近年來平台端的改進（例如 SnapStart、Provisioned Concurrency）已經大幅降低冷啟動的影響，但對於延遲敏感的場景，仍然需要實測驗證。
供應商鎖定（Vendor Lock-in） 指的是應用程式與特定雲端平台的 API、事件模型、部署工具深度綁定，導致未來遷移成本高昂。這是無伺服器最常被批評的一點。缓解策略包括：使用開源框架（例如 Serverless Framework、SAM、SST）來抽象部署流程；把業務邏輯與平台 API 解耦；選擇支援多雲的執行環境（例如 Kubernetes 上的 Knative、OpenFaaS）；以及在架構設計時保留「可替換」的介面。完全避免鎖定並不容易，但可以透過設計降低遷移成本。
可觀測性（Observability） 指的是在分散式、事件驅動的架構中，如何追蹤單一請求的完整路徑、如何關聯日誌與指標、如何快速定位問題。無伺服器把應用拆成許多小函式，每個函式都有自己的日誌與指標，傳統的監控方式很難應付。實務上需要搭配分散式追蹤（例如 OpenTelemetry、AWS X-Ray）、結構化日誌、集中式日誌平台與自訂指標。這部分的工具鏈仍在快速演進，團隊需要投入一定的學習成本。
4.3 成本監控與架構治理
無伺服器的計費模式雖然彈性，但也容易造成「不知不覺的浪費」。常見的成本陷阱包括：函式記憶體設定過高、重試機制設計不良導致重複執行、日誌與追蹤資料存放過久、開發環境沒有設定資源上限等。這些問題在傳統架構中同樣存在，但在無伺服器環境中更容易被忽略，因為沒有「機器」可以直觀地看到資源使用率。
因此，導入無伺服器時，成本監控必須從第一天就建立。實務做法包括：為每個環境與團隊設定預算告警；使用平台提供的成本分析工具（例如 AWS Cost Explorer、Azure Cost Management）；定期檢視高成本函式並優化記憶體與逾時設定；把成本指標納入 CI/CD 流程，讓每次部署都能看到預估成本變化。
架構治理則是另一個重點。無伺服器讓開發者可以快速建立資源，但如果不加以治理，很容易出現「函式蔓延」——數百個小函式散落各處，沒有人清楚它們的用途、擁有者與生命週期。實務上需要建立命名規範、標籤策略、資源清單與定期清理機制，並把架構決策文件化，讓團隊成員能夠理解整體設計。
五、真實案例與生態觀察
從產業實務來看，無伺服器在 SaaS 領域的應用已經相當普遍，只是多數產品不會特別強調。以下是幾個常見的應用模式：
模式一：事件驅動的資料管道。 許多 SaaS 產品需要處理使用者上傳的檔案、匯入的資料、第三方服務的 Webhook。這些任務通常具有「間歇性、可平行、容忍延遲」的特性，非常適合用無伺服器函式來處理。例如，使用者上傳 CSV 檔後，觸發函式進行解析、驗證、寫入資料庫，並透過佇列處理失敗重試。
模式二：API 周邊的輕量端點。 核心 API 可能仍運行在容器或 VM 上，但周邊的認證回呼、健康檢查、表單提交、短網址導向等端點，則可以用無伺服器實作。這種「混合架構」讓團隊可以在不重寫核心系統的前提下，逐步享受無伺服器的好處。
模式三：多租戶的自動化工作。 例如每個租戶的每日報表產生、資料備份、通知發送等。這些工作可以透過排程觸發，搭配租戶 ID 參數執行，避免為每個租戶維護獨立的伺服器。
模式四：內部工具與自動化。 許多 SaaS 團隊會用無伺服器來建立內部工具，例如部署通知、監控告警、客服工單自動分類等。這些工具不需要高可用性保證，但需要快速迭代，無伺服器正好符合需求。
從生態角度來看，無伺服器的工具鏈在過去幾年快速成熟。部署框架（Serverless Framework、SAM、SST、CDK）讓基礎設施即程式碼（IaC）變得更容易；可觀測性工具（Datadog、New Relic、OpenTelemetry）開始支援分散式追蹤；安全工具（Snyk、Checkov）可以掃描函式設定與權限；成本工具（Infracost、CloudHealth）可以預估與監控支出。這些工具的成熟，降低了無伺服器的導入門檻，也讓團隊能夠更專注在產品本身。
六、結論與建議
回顧整條演進路線，SaaS 的發展本質上是一場「抽象化」的過程：從使用者自己管理伺服器，到供應商代管伺服器，再到平台自動管理執行環境。無伺服器並不是這個過程的終點，而是目前為止抽象層級最高的一個階段。它把「執行環境的管理責任」轉移到雲端供應商，讓 SaaS 團隊可以用更少的資源、更快的速度、更低的風險來打造產品。
但無伺服器也不是萬靈丹。它有明確的適用邊界，也有冷啟動、供應商鎖定、可觀測性等實務挑戰。成功的導入策略，通常是「混合架構」：把穩定基載放在預留資源上，把突發與周邊任務交給無伺服器，並透過成本監控、架構治理與可觀測性工具來維持系統品質。
對於正在評估無伺服器的 SaaS 團隊，以下是幾點實務建議：
軟體產業的演進從來不是一條直線，而是一連串「在限制中尋找最佳解」的過程。無伺服器之所以會在 SaaS 領域站穩腳步，並不是因為它比較時髦，而是因為它回應了現代軟體團隊最真實的痛點：用更少的維運換取更快的迭代、用更彈性的成本結構換取更大的成長空間。當我們把視角從「技術選擇」拉高到「組織能力」時，就會發現無伺服器的真正價值，不只是架構上的簡化，而是讓團隊能夠把有限的注意力，集中在真正重要的事情上——打造讓使用者願意持續付費的產品。