Day25 把 ProjectManagementWeb 的程式、測試與文件重新對齊，也留下第一個可交付的版本。現在，Vue 3 前端、ASP.NET Core API 與 SQL Server 都能在開發電腦上運作。
但是網站還沒有真正「搬出去」。只要關掉開發電腦，其他人就無法使用它。
如果把程式想成一家準備開幕的店，寫完程式只是把店內整理好，接下來還要找店面、接水電、裝門鎖，也得確認每個月付得起帳單。雲端服務就是我們這次要租的「營業場地」。
這一篇先不急著按下建立資源的按鈕。我們會先弄懂雲端服務在做什麼，再替 ProjectManagementWeb 挑選合適的 Google Cloud 服務。Day27 才會實際進行部署。
「雲端」這個名字很容易讓人覺得抽象，但它背後依然是一台台實體伺服器、硬碟與網路設備。這些設備放在雲端供應商的資料中心，由供應商統一維護。
差別在於，我們不用先買一整套設備，可以透過管理畫面或 API 申請伺服器、儲存空間或資料庫，再按照資源的規格與用量付費。
左邊像自己蓋一間店，從建物、水電到維修都要處理；右邊則像租用已經接好基礎設施的店面。租店面可以少管一些事，卻不等於從此什麼都不用管。程式有沒有安全漏洞、誰拿得到門鎖鑰匙、資料要保留多久，仍然是我們的責任。
NIST 對雲端運算的定義列出五個基本特性。換成日常用語，可以這樣理解：
| 特性 | 白話解釋 |
|---|---|
| 隨選自助服務 | 需要資源時可以自己申請，不必等供應商派人安裝。 |
| 廣泛的網路存取 | 只要網路與權限正確，不同裝置都能使用服務。 |
| 資源池化 | 供應商集中管理大量設備，再把資源分配給不同客戶。 |
| 快速彈性 | 需求增加時可以擴充，流量下降時也能縮減。 |
| 可計量服務 | CPU、儲存空間、請求次數與網路流量等用量可以被記錄與計費。 |
最後一點要特別留意。「按用量付費」不是「一定比較便宜」，更不是「免費」。測試完忘記刪除資源、保留太多 Log，或讓服務沒有上限地擴充，都可能讓帳單慢慢長大。
雲端服務常用 IaaS、PaaS 與 SaaS 分類。名字看起來很多，其實只是在回答同一個問題：「供應商幫我們管到哪裡？」
| 類型 | 可以先想成 | 我們主要管理什麼 | Google Cloud 或常見例子 |
|---|---|---|---|
| IaaS（基礎架構即服務） | 租一間空屋 | 作業系統、Runtime、程式與資料 | Compute Engine |
| PaaS（平台即服務） | 租已有基本裝潢的店面 | 程式、設定與資料 | App Engine |
| Serverless（無伺服器） | 租可依客流調整大小的店面 | 程式或容器、服務設定與資料 | Cloud Run、Cloud Run functions |
| SaaS（軟體即服務） | 直接進入已經營業的店家 | 帳號、內容與使用設定 | Gmail、Google Docs |
Serverless 不是「沒有伺服器」，而是使用者不必建立與維護底層主機。它常被視為 PaaS 的延伸，這裡單獨列出，是因為 ProjectManagementWeb 會使用 Cloud Run。
供應商接手的工作越多，開發者通常能越快部署，但可自由調整的底層細節也會變少。這不是四選一的考試題，同一個系統裡本來就可以同時使用不同類型的服務。
Google Cloud 不是一個單一產品，而是 Google 提供的一組雲端服務。裡面有虛擬機器、容器平台、資料庫、檔案儲存、網路、監控與 AI 工具。
第一次打開 Google Cloud Console 時，產品名稱會多到像走進大型工具行。先不要逐項背起來，只要先認識 Project、Region 與 Zone，就有足夠的地圖可以往下走。
Google Cloud 的 VM、資料庫與儲存空間都會放在某個 Project 底下。哪些 API 已啟用、誰有權限操作，以及費用算到哪裡，也都會用 Project 作為重要的管理邊界。
可以把 Project 想成專案的工具箱：雲端資源放在裡面，權限是工具箱的鑰匙，Billing Account 則是付帳的方式。建立 Project 或啟用 API，不等於已經建立了付費的 VM 或資料庫；真正建立資源後，才要依它的計價方式留意費用。
個人練習可以先使用一個 Project。公司環境則常把開發、測試與正式環境分開，免得權限、資源和帳單全擠在同一個工具箱裡。
Region 是一個地理區域，例如台灣的 asia-east1；Zone 則是 Region 裡更細的部署區域，例如 asia-east1-a。
不是每種服務都有 Zone 的概念，可用的 Region 也不一定完全相同。選擇位置時，要看使用者在哪裡、網路延遲、資料法規、可用性與費用。後面部署的 Cloud Run 與 Cloud SQL 也會盡量放在同一個 Region，減少跨區連線的複雜度。
Google Cloud 的產品很多。對剛接觸雲端的人來說，最實用的方法不是把產品目錄背完，而是先問「現在要解決什麼問題？」
| 我現在需要什麼？ | 可能遇到的服務 | 它大概在做什麼？ |
|---|---|---|
| 一台可自由安裝軟體的電腦 | Compute Engine | 建立 VM，作業系統與軟體由使用者管理。 |
| 執行容器化的網站或 API | Cloud Run | 執行容器，不必自行維護 VM 或 Kubernetes 叢集。 |
| 管理多個容器與叢集 | Google Kubernetes Engine（GKE） | 提供 Google 代管的 Kubernetes 環境。 |
| 保存圖片、影片或備份檔 | Cloud Storage | 保存物件檔案，不是關聯式資料庫。 |
| 保存關聯式資料 | Cloud SQL | 代管 MySQL、PostgreSQL 與 SQL Server。 |
| 保存 Docker 映像 | Artifact Registry | 放置要交給 Cloud Run 執行的容器映像。 |
| 保存密碼與連線字串 | Secret Manager | 讓機密不必寫進程式碼或映像。 |
| 查看 Log 與系統指標 | Cloud Logging、Cloud Monitoring | 集中查詢執行紀錄，並觀察服務狀態。 |
| 定時啟動一項工作 | Cloud Scheduler、Cloud Run job | 在指定時間觸發一次性工作。 |
還有 VPC、Cloud Build、Firestore、Pub/Sub、BigQuery 與 Vertex AI 等許多服務，可以等專案真的出現對應需求再引入。服務多一個，就多一份權限、費用與故障排除工作。完整產品仍以 Google Cloud 產品目錄為準，這裡先記住 ProjectManagementWeb 會用到的就好。
這次的目標是讓現有系統可以在雲端運作，不是為了把每種 Google Cloud 產品都用一次。依目前的前後端與資料庫架構，先選擇下列服務：
| 系統內容 | 選擇的服務 | 為什麼這樣選？ |
|---|---|---|
| Vue 3 前端 | Cloud Run service | 將建置後的靜態檔放進 Web Server 容器，前後端可以使用相近的映像與部署流程。 |
| ASP.NET Core API | Cloud Run service | 後端已有 Dockerfile，Cloud Run 可以執行容器並提供 HTTPS 網址。 |
| SQL Server | Cloud SQL for SQL Server | 保留現有的關聯式資料模型，並讓平台協助處理底層維運。 |
| DbUp 資料庫遷移 | Cloud Run job | 需要時執行 Schema 變更，完成就結束，不必持續監聽 HTTP 請求。 |
| 到期提醒 | Cloud Scheduler、Cloud Run job | 由 Scheduler 定時觸發工作，不假設網站容器會永遠在背景運作。 |
| Docker 映像 | Artifact Registry | 保存前端、API 與遷移工作的映像。 |
| 連線字串與 JWT Key | Secret Manager | 機密資料不寫進原始碼、映像或 Git。 |
| 執行紀錄與指標 | Cloud Logging、Cloud Monitoring | 集中查看前後端的 Log 與基本運作狀態。 |
這不是唯一答案。例如 Vue 前端也可以放在 Firebase Hosting，或使用 Cloud Storage 搭配外部 Application Load Balancer 與 Cloud CDN。這次選 Cloud Run，是為了讓前後端共用相近的容器部署觀念，不代表它在每種流量與價格條件下都最便宜。
Cloud SQL for SQL Server 也是為了沿用目前的 SQL Server 設計。它會產生運算、儲存與 SQL Server 授權等費用，不是沒人瀏覽就一定歸零。如果只想用最低成本展示小型作品，應另外比較資料庫方案，不該照抄這組架構。
把前面選的服務放回同一張圖，關係如下：
使用者先透過瀏覽器開啟 Vue 前端，Vue 再以 HTTPS 呼叫 ASP.NET Core API。API 負責處理權限與業務規則，最後才讀寫 Cloud SQL；瀏覽器不會直接連進資料庫。
Artifact Registry 像倉庫，放著已建置的容器映像。Secret Manager 則像上鎖的鑰匙櫃，在執行時才把連線字串與 JWT Key 交給有權限的服務。
API 與 Cloud SQL for SQL Server 之間預定使用私有 IP。這條路不是勾選「Private IP」就自動打通：Cloud SQL 需要 Private Services Access，Cloud Run 也要透過 Direct VPC egress 或 Serverless VPC Access connector 進入同一個 VPC。這些設定會放在 Day27 處理。
Day16 曾經用 Hangfire 設定到期提醒。放到 Cloud Run 後，不能直接假設同一個排程器會一直待在背景執行。
Cloud Run service 預設會依請求數量調整執行個體，沒有流量時可能縮到 0；在 request-based billing 下，容器也不會在一般的請求處理之外持續取得 CPU。就算保留最少執行個體，還得考慮重啟、多個執行個體重複執行與持續計費。
這次會把定時任務的「鬧鐘」交給 Cloud Scheduler，時間到再啟動 Cloud Run job。這樣比把排程器塞在網站服務裡，更符合目前的 Cloud Run 執行方式。部署環境不同，程式設計也要跟著調整。
第一次用雲端服務，很容易只關心網站能不能開啟。不過在真正建立資源前，還要看權限、資料復原與費用通知有沒有安排好。
雲端供應商負責資料中心與底層服務，不會自動修正過度寬鬆的 IAM 權限、外洩的 JWT Key 或有漏洞的程式。正式服務應使用專用 Service Account，並只給它完成任務所需的權限。
Cloud SQL 會幫忙處理許多底層維運工作，但備份時間、保留期間與還原方式仍要確認。只看到「已啟用備份」還不夠，真正需要時能不能還原，才是備份的答案。
建立 Billing Budget 與通知可以及早發現費用異常。一般的預算通知是警報器，不是會自動關閉總電源的開關。達到門檻後，服務可能繼續運作與計費。
Cloud SQL 這類持續配置的資源，就算沒有人瀏覽網站，也可能繼續產生費用。練習完成後，要回到資源清單確認哪些還在運作，並刪除不再需要的資源。
雲端服務不是把檔案丟到網路上，而是向供應商申請運算、儲存、資料庫與網路等資源。供應商幫我們接手一部分底層維運，程式、權限、資料與費用仍然需要人管理。
ProjectManagementWeb 會使用 Cloud Run 執行 Vue 前端與 ASP.NET Core API，用 Cloud SQL for SQL Server 保存資料，再以 Artifact Registry、Secret Manager、Cloud Logging 與 Cloud Monitoring 補上映像、機密與觀測能力。定時工作則會改由 Cloud Scheduler 觸發 Cloud Run job。
現在服務選好了，連線方向與風險也比較清楚。下一篇會進入 Google Cloud Console，從 Project、Billing 與必要 API 開始，一步步把這張架構圖變成真正可連線的環境。
iThome鐵人賽
看影片追技術