[已讀亂回]「離不開 Zeabur」是哪一種離不開？
最近 Threads 上一篇關於 Zeabur 漲價的串文蠻熱鬧的。原文是 hanbingjheng 寫的，留言區也接了一輪。我自己順手在底下留了一則回應。
原文走的是直接結論 — 「搬不走」。整篇在嚴厲呼喚一種具體想法：當初為了省工程師費上的平台、漲價時又得花工程師搬走；上雲前要算「我搬一次要花幾個人天」；便宜跟方便的代價就是漲價來時你只能照付。
讀完當下，我腦袋裡跳到了另一個層次的東西：vendor lock-in。原文沒有用這個詞，但身為讀者，我習慣性把眼前的觀察往一個更大、更泛化的概念上 abstract，看看抓到的是不是同一件事。所以這篇要衡量的不是「原文對不對」，是「搬不走」這個直接結論，跟「vendor lock-in」這個泛化概念之間到底有多近。
量距離的方法，是拿我自己的 vendor lock-in 快篩試紙來測這次的場景。測完發現，兩條 red flag 都沒亮。對 Zeabur 上的多數場景來說，你需要的不是 lock-in 這個大概念，而是 application（或 service）跟 data 各別的搬遷計劃而已。
原文摘錄
把整套系統壓在一家雲端平台上，省的是眼前的工程師費，賭的是這家永遠不漲價。
這幾天 Threads 上看到一堆開發者在罵某家台灣部署平台漲價。有人貼出帳單，月費大概漲了六成。留言區吵的是貴。我看到的是另一件事：他們搬不走。
麻煩在漲價那封信寄來的時候。你想換一家，才發現要重新部署、把資料庫搬過去、網域和通知信全部重接，再從頭測一輪。而這些事，要找的正是你當初想省掉的那個工程師。
省下的是工程師。真的要搬家，賠回去的還是工程師。這就是為什麼平台敢一年漲兩次，他賭你嫌麻煩、不會走。
他第二段補了「上雲三問」（資料能否整包匯出、用了幾個獨家功能、過去兩年調價幾次）作為決策 checklist。三問本身合理，但跟「Zeabur 算不算 lock-in」是不同題目，這篇就不展開。
留言區有兩個方向我也想一起放進來：
cashwugeek：「用 docker 部署哪裡不好搬家，不就叫 AI 處理就好。」dlutermade0.0：「你誤解了，那家是最好搬家的。GCP 的 BigQuery、GCS，Firebase 的 Firestore、Auth，AWS 的 Dynamo、S3 — 這些才是難搬的。」
兩則留言的觀察跟我的論點同向，後面會接著講。
Vendor lock-in 的快篩試紙
試紙上要看兩條線：
- 技術獨佔 — 找替代方案的代價很大（不是慢一點、貴一點，是「換掉這個服務之後同類功能要重寫一輪」）
- 資料量大到難搬（搬移動作本身就是個專案，光備份還原就要排幾天起跳）
任何一條亮 red flag 都得停下來認真看，但最棘手的是兩條一起亮 — 既獨佔、又有大量資料堆在上面。dlutermade0.0 在留言區舉的例子裡，BigQuery、Firestore、DynamoDB 就是典型的兩個 red flag 同時亮：服務本身的查詢語意 / 資料模型很獨家，搬走要重寫業務邏輯；同時資料量又大到搬移本身就是個專案。（同一則留言提到的 S3、GCS 嚴格說來不算 — 純物件儲存有 S3-compatible API 撐著，搬到 R2 / Minio 是機械動作；要綁上 S3 Select、Athena 這類查詢服務才會升級成 red flag。）
這張試紙對我來說就是 lock-in 的真實重量。其他「不方便」、「要花時間」我會先當成搬遷成本、不馬上升級成 lock-in。
拿試紙測 Zeabur 場景
第一條：技術獨佔。Zeabur 本身建在 k8s 之上、封裝了一層自家環境，部署單位是 container image。image 本身是業界標準格式、不被綁死，但別把它當成「搬過去就跑」的單位 — ingress、服務間連接、env var 注入這些介面各家做法不同，要重接一次。前幾年 Heroku 取消免費方案的時候，大批使用者搬到 Fly.io、Render 這些還免費或平價的同級平台，搬遷工作主要就是把這些介面重接。資料庫 addon 走的也多半是標準協議（Postgres、Redis）。各家平台在細節上總有些調整要做，但量不多；加上 AI 輔助，沒有實際的技術難題會卡死你。技術沒有獨佔，這條沒亮。
第二條：資料量大。Zeabur 吸引到的使用者，主要是想用平價算力跑東西、又不想碰底層細節的這群人。手上跑的多是 side project、內部小工具、demo 站、blog 這類，資料量在「一份 SQL dump 幾 MB 到幾百 MB」的等級。這份重量還不到「搬移本身就是個專案」，這條也沒亮。
兩條 red flag 都沒亮 — 至少對「Zeabur 上跑的典型專案」是這樣。
這跟原文要點出的問題不在同一個層次。原文點出的是「漲價了我搬不走」，但「搬不走」這個感受，跟「真的鎖死了搬不走」中間還有一段距離要走。
那麼，如何順利搬家？
試紙都沒亮，剩下的就是把「實際怎麼搬」這份 plan 寫出來。對外服務跟純內部跑的場景需要的項目不太一樣，但骨幹大致是這三塊：
第一塊（對外服務才需要）— domain name 跟 DNS TTL 的轉移。確認 domain 在誰手上、能不能拿回來；把 TTL 提前降到很短讓切換生效得快；規劃切換窗口跟舊機器的 fallback 期；新平台的 SSL/TLS 怎麼簽。對外服務這塊要最先排，因為 DNS propagation 是個外部時間軸，沒辦法用程式碼縮短。
第二塊 — runtime environment，對應試紙第一條（技術獨佔）。Dockerfile 還 build 得起來；環境變數、secret 在新平台怎麼注入；ingress / 路由 / custom domain 怎麼接；service-to-service 連接方式；log 跟 metrics 怎麼收。
第三塊 — data migration，對應試紙第二條（資料量大）。DB dump 跟 restore；物件儲存怎麼複製；切換期間的 dual-write 或 read-only 策略；如果新平台有問題怎麼切回去。
三塊各自都有具體動作、可預期的時間、可驗證的完成標準。實際上不需要等到自己累積出肌肉記憶才動 — 用 agentic AI 輔助、在新 service provider 上把 runtime 那塊建起來，三塊裡頭最仰賴經驗的部分就過了；剩下 domain 切換、data 轉移就是按計劃接著做的工。
沒摸過 Cloud Run / Fly.io / 自架 VPS 的人也是這樣 — 問 AI、跟著它走一輪、出錯讓它幫忙解，短時間內就能把這次搬家的評估做完；甚至可以順著新 service provider 的 network transfer 價目表，把整次搬家的預估費用算出來。
cashwugeek 那句「用 docker 部署哪裡不好搬家」站在熟悉這側看本來就輕鬆。在 AI 時代更是這樣 — plan 跟 execution 都能 AI 代勞，計劃負責人剩下的事是加上「約束」：能不能 rollback、哪裡可能會出事、出事了怎麼 rollback。
站在另一側的人沒寫過時抬頭看一片黑，搬遷成本就會被算成「我得花多久才能搞懂這套」 — 這個數字暫且是個未知，於是結論變成「搬不動」 — 但「搬不動」只是描述、不等於 lock-in，它測的其實是熟悉度的差距，是認知摩擦、不是技術鎖。對非 serverless / 其他正規 CSP（Cloud Service Provider）不熟的時候，連 plan 應該長什麼樣都沒概念，這份感受最強。
只要靜下心、讓有經驗的人（AI 或真人）陪你拆一遍，就能得出一個合理的結論。比起最初迷霧未開的時候，這個版本看得清楚得多，並且知道哪些是自己擔得起的。
不妨用著這次價格調整所產生的動機，把這份搬家 plan 擬一份出來、跑過一次。下次再面對類似選擇 — 不管是想搬還是想留 — 手上就多了真實對照組可以判斷，主動權回到自己手上。
順帶一筆：如果不先說在談「搬家」，把這份 plan（DNS / runtime / data + rollback / 出事點）拿給資深維運看，他會以為我們在討論災難復原（disaster recovery）。骨架同一份 — 差別在出發的契機：主動切換 vs 被動回復。