本篇重點
- 分析五大雲端服務模型（IaaS、CaaS、PaaS、FaaS、SaaS）的核心架構
- 區分各服務硬體、虛擬化、作業系統、應用程式等層級的管理歸屬
- 各服務模型的代表性產品、管理複雜度及適用場景
從實體硬體到軟體應用，雲端服務的核心在於將不同層級的技術資源根據使用者的需求提供不同程度的管理權限。
IaaS 基礎設施即服務
Infrastructure as a Service
提供最基礎的運算資源，供應商負責實體資料中心、網路、伺服器硬體及虛擬化技術，用戶則擁有虛擬機以上的完整控制權，需要自行管理，相當於租用一台遠端伺服器。
管理範圍
- 雲端廠商負責實體資料中心、網路、儲存設備、虛擬化技術。
- 用戶負責安裝與維護作業系統（OS）、中間件（Middleware）、執行環境（Runtime）以及所有應用程式與數據。
代表產品
Amazon EC2、Google Compute Engine (GCE)、Azure Virtual Machines。
適用對象
需要高度客製化環境、運行遺留系統（Legacy Systems）或具備強大運維團隊的企業。
例如
- 自行管理 Kubernetes cluster
- 高度客製化企業系統
CaaS 容器即服務
Container as a Service
介於 IaaS 與 PaaS 之間，專注於容器的部署與編排，簡化了基礎設施的管理，讓開發者專注於容器映像檔（Container Images），是專門為容器化應用（Containerized Application） 設計的雲端服務。
管理範圍
- 雲端廠商負責管理叢集（Cluster）底層基礎設施、容器執行環境。
- 用戶負責容器映像檔、應用程式碼及容器編排設定。
代表產品
Google Kubernetes Engine (GKE)、Amazon EKS、Azure AKS。
適用對象
採用微服務架構、需跨雲平台移植（Portability）、CI/CD 容器部署的開發團隊。
例如
- 以 Docker + Kubernetes 部署 API 服務
- DevOps 團隊進行自動化部署
PaaS 平台即服務
Platform as a Service
消除作業系統與中間件的管理負擔，提供完整的應用開發、測試與部署平台。
管理範圍
- 雲端廠商負責管理作業系統（OS）、執行環境（Runtime，如 Java、Node.js、Python runtime）、自動部署、自動縮放機制（Auto Scaling）。
- 用戶僅需上傳程式碼並配置相關設定。
代表產品
Google App Engine、Netlify、Heroku、AWS Elastic Beanstalk。
適用對象
Web 應用開發、API Server，希望將資源集中於產品邏輯而非基礎架構的開發者。
例如
- Node.js API
- Python Web Application
- RESTful Service
FaaS 函數即服務
Function as a Service
「無伺服器運算」（Serverless）架構的一種實作方式，簡化成單一函數層級，僅在特定事件觸發時才執行。
管理範圍
- 雲端廠商負責底層資源調度、執行環境與擴展。
- 用戶僅撰寫並上傳特定邏輯的函數代碼。
代表產品
AWS Lambda、Google Cloud Functions、Azure Functions。
適用對象
事件驅動型任務、非同步處理、API 後端處理、低頻率或突發性流量的任務。
例如
- 圖片上傳後自動壓縮
- webhook 事件處理
- IoT 資料處理
SaaS 軟體即服務
Software as a Service
用戶直接透過網路瀏覽器或 API 使用完整的應用軟體。
管理範圍
- 雲端廠商負責從硬體到軟體的所有層級。
- 用戶僅負責設定軟體參數與使用功能。
代表產品
Salesforce、Microsoft 365、Slack、Gmail。
適用對象
企業通用辦公需求、客戶關係管理或不具備軟體開發能力的一般企業用戶。
雲端服務模型分析
各服務模型在控管能力與複雜度（客製化能力）上的差異：
| 服務類型 | 核心控管層級 | 管理複雜度 |
|---|---|---|
| IaaS | 虛擬主機與網路 | 最高 |
| CaaS | 容器與編排 | 高 |
| PaaS | 應用程式碼 | 中 |
| FaaS | 函數代碼 | 低 |
| SaaS | 終端軟體設定 | 最低 |
結論
雲端服務模型反映了系統管理責任在廠商與使用者之間的分工差異。
工程團隊在選擇雲端服務時，通常可以根據以下因素決定：
- 系統架構（Monolith / Microservices）
- DevOps 能力
- 維運成本
- 擴展需求
