Google Cloud 停服墓園：那些被砍掉的服務，以及你該注意的遷移時間
你有沒有在 Google Cloud Console 裡看過這種橫幅：
⚠️ This product has been deprecated and will be shut down on [某個日期].
如果有，你不孤單。Google Cloud 停掉的服務數量，在三大雲端裡名列前茅。
上一篇我們聊了 Google Cloud 40+ 次的產品改名歷史。改名至少服務還在，更讓人緊張的是，有些服務直接消失了，而且沒有 Google 自家的替代方案。
這篇幫你整理「Google Cloud 墓園」，分成三個區塊：已經停服的、即將停服的、以及 Google 在停服政策上的改善。
已停服：安息的服務們
最具爭議的停服案例
Cloud IoT Core（2017-2023）
| 項目 | 內容 |
|---|---|
| 停服公告 | 2022 年 8 月 |
| 最終關閉 | 2023 年 8 月 16 日 |
| 替代方案 | 沒有 Google 自家替代品，建議遷移到第三方（ClearBlade 等） |
這大概是 Google Cloud 停服史上吵最兇的一次。很多客戶整套 IoT 產品線都蓋在它上面，結果 Google 說砍就砍，也沒給自家替代方案，一堆人只能被迫搬去 AWS IoT Core 或 Azure IoT Hub。
後來這個案例常被拿來當「Google 不適合做企業基礎建設」的證據。
Google Stadia（2019-2023）
| 項目 | 內容 |
|---|---|
| 停服公告 | 2022 年 9 月 |
| 最終關閉 | 2023 年 1 月 18 日 |
| 替代方案 | 無（消費者服務直接關閉，底層技術轉為內部使用） |
Stadia 雖然是消費者產品、不算雲端基礎設施，但它成了「Killed by Google」現象的代表作。比較少見的是，Google 這次把所有遊戲購買都全額退款了。
Hire by Google（2017-2020）
| 項目 | 內容 |
|---|---|
| 停服公告 | 2019 年 8 月 |
| 最終關閉 | 2020 年 9 月 1 日 |
| 替代方案 | 無（建議遷移到第三方 ATS） |
這個產品來自 Google 以 3.8 億美元收購的 Bebop。業界普遍認為，這筆收購真正的目的是把 Diane Greene 找來當 Google Cloud CEO，產品本身只是順便。
技術整合型停服
這類停服有個共同點：服務被併進更大的平台，而且有明確的遷移路徑。
| 服務 | 存活期 | 關閉日期 | 替代方案 |
|---|---|---|---|
| Google Prediction API | 2010-2018 | 2018.05 | Cloud ML Engine → Vertex AI |
| Cloud Datalab | 2015-2020 | ~2020 | Vertex AI Workbench |
| AI Platform (legacy) | 2017-2025 | 2025.01 | Vertex AI |
| Container Registry | 2014-2025 | 2025.03 起分階段關閉（詳見下方 2025 停服潮） | Artifact Registry |
| AutoML Tables (legacy) | 2019-2024 | 2024.07 | Vertex AI AutoML |
| Google Cloud Messaging | 2012-2019 | 2019.04 | Firebase Cloud Messaging |
其他已停服
| 服務 | 關閉日期 | 替代方案 |
|---|---|---|
| Cloud Debugger | 2023.05 | 無完整替代（開源 Snapshot Debugger 也已封存） |
| Cloud Endpoints Portal | 2023.03 | API Gateway |
| Google Cloud Print | 2020.12 | Chrome OS 原生列印 |
| Google+ API | 2019-2020 | 無（因資安漏洞加速關閉） |
2025-2026 停服潮
2025-2026 是 Google Cloud 歷史上停服最密集的時期之一。
2025 年（已完成）
| 服務 | 停服日期 | 替代方案 | 狀態 |
|---|---|---|---|
| Container Registry（停止讀取） | 2025.06.03 | Artifact Registry | ✅ 已關閉 |
| Container Registry（完全關閉） | 2025.10.14 | Artifact Registry | ✅ 已關閉 |
| Cloud Life Sciences | 2025.07.08 | Batch | ✅ 已關閉 |
| Firebase Dynamic Links | 2025.08.25 | 第三方（Branch、AppsFlyer） | ✅ 已關閉 |
| AutoML Vision/NL/Video (legacy) | 2025.09.30 | Vertex AI | ✅ 已關閉 |
| Cloud Composer 1（停止新建） | 2025.09.15 | Cloud Composer 2/3 | ✅ 已停止新建 |
| Cloud Deployment Manager（停止支援） | 2025.12.31 | Infrastructure Manager / Terraform | ✅ 已停止支援 |
| MQL（Cloud Monitoring 查詢語言） | 2025.07.22 | PromQL | ✅ 已關閉 |
2026 年
| 服務 | 停服日期 | 替代方案 | 緊急度 |
|---|---|---|---|
| App Engine 舊版 Runtime（Python 2.7、Java 8、Go 1.11、PHP 5.5） | 第二代 Runtime | 🔴 立即遷移 | |
| Data Catalog | Dataplex Universal Catalog | ✅ 已完成 | |
| Pub/Sub Lite | Pub/Sub 標準版 / Managed Kafka | ✅ 已完成 | |
| Cloud Deployment Manager（完全關閉） | Infrastructure Manager / Terraform | ✅ 已完成 | |
| BigQuery Legacy SQL（使用限制） | 2026.06.01 | Standard SQL | 🟡 中 |
| Document AI Legacy Processors | 2026.06.30 | 更新版 Document AI on Vertex AI | 🟡 中 |
| Cloud Composer 1（完全關閉） | 2026.09.15 | Cloud Composer 2/3 | 🔴 高 |
2027-2029
| 服務 | 停服日期 | 替代方案 |
|---|---|---|
| functions.config API（Firebase） | 2027.03 | 環境變數 / Secret Manager |
| Memorystore for Memcached | 2029.01.31 | Memorystore for Valkey |
Google 的停服政策：有在改善嗎？
信任危機
2020 年，前 Google 工程師 Steve Yegge 發表了一篇引起廣泛討論的公開信：
《Dear Google Cloud: Your Deprecation Policy Is Killing You》
重點是：Google 動不動就停服的習慣，正在一點一點吃掉企業客戶的信任。對比之下，AWS 幾乎從不停服任何服務，就算是十年前推出、根本沒幾個人用的服務，它也會繼續養著。也因為這樣，企業挑雲端平台時，往往把「穩定性」算進 AWS 的關鍵優勢。
Google 的回應：Enterprise API 政策
2021 年，Google 正式推出了 Enterprise API 標籤，受更嚴格的停服政策保護：
| 面向 | 舊政策 | Enterprise API 政策 |
|---|---|---|
| 停服預告期 | 通常 12 個月 | 至少 1 年，實務上多為 2-4 年 |
| 相容性保證 | 不明確 | 主版本內向後相容 |
| 遷移支援 | 視情況 | 提供遷移工具和文件 |
有在改善的證據：Memorystore for Memcached 的停服預告期拉到 4 年以上（2024 年宣佈，2029 年才關），這在早期根本不可能發生。
三大雲停服哲學比較
| AWS | Azure | Google Cloud | |
|---|---|---|---|
| 停服頻率 | 極低 | 中等 | 較高 |
| 預告期 | N/A（幾乎不停服） | 通常 12-24 個月 | 12-48 個月（持續改善中） |
| 替代方案 | N/A | 通常有 | 多數有，少數沒有 |
| 哲學 | 永不拋棄 | 跟隨市場 | 快速迭代，汰弱留強 |
停服背後的規律
把整份墓園清單看完，大概可以歸納出幾種模式：
1. 市場失敗型（最痛）
IoT Core、Stadia、Hire——這些服務在競爭裡打輸了，Google 乾脆直接退出那個市場。這類通常沒有 Google 自家替代方案，用戶只能搬去競爭對手或第三方。
2. 技術整合型（最常見）
Prediction API → Vertex AI、Container Registry → Artifact Registry、Stackdriver → Cloud Operations——舊服務被更能打的新平台吸收掉。這類通常有明確的遷移路徑。
3. 收購消化型
API.AI → Dialogflow、Siemplify → Chronicle SOAR → Google SecOps——收購來的產品逐步融入 Google Cloud 體系，品牌名消失但功能保留。
4. 技術債清理型
App Engine 舊版 Runtime、BigQuery Legacy SQL、Cloud Composer 1——底層架構太舊了，Google 推著用戶升級到新版本。
實務建議：如何降低停服風險
- 訂閱 Google Cloud Release Notes：停服公告通常在這裡首次出現
- 定期檢查 cloud.google.com/terms/deprecation：官方停服清單
- 避免過度依賴小眾服務：使用者基數太小的服務停服風險較高
- 優先選擇有 Enterprise API 標籤的服務：受更嚴格的停服政策保護
- 建立抽象層：在應用程式和雲端服務之間建立抽象層，降低遷移成本
- 關注 Killed by Google（killedbygoogle.com）：社群維護的 Google 停服追蹤器
一句話總結
Google Cloud 的停服史確實比 AWS 和 Azure 精彩很多，但這幾年的改善也是真的。不是不能用 Google Cloud，而是要用對方式：挑核心服務（Compute Engine、GKE、BigQuery、Cloud Storage），別把賭注押在邊緣產品上，然後訂閱停服通知，給自己留足遷移的時間。
畢竟，在雲端世界裡，唯一不變的就是變化本身。