Zeabur 到底為你做了什麼？

延續昨天 Zeabur 價格調整的議題，我們來討論一下這類平台服務實際做了哪些事，而我們該怎麼挑選適合的。

既然是 Zeabur 開啟的討論，這篇會先排除 serverless 類型，例如 Vercel、Netlify、AWS Lambda，它們的計價方式和技術特點，都和一般平台有區別。

而一個合格的平台，應該被賦予完整的 SaaS 精神：減少原始工作的負擔，以及利用資源共享的方式來壓低成本，配合訂閱制來減低價格。前者讓使用者省力省時間，而後者就是省錢了。

所以我們可以從這兩個角度來看整件事情。

減少工作量

進入雲端時代後，我們一直希望有一組輕便、簡易又通用的伺服器框架，讓我們能快速把產品部署出去。但一台伺服器要管理和設定的東西實在太多，即使有許多廠商投入提供類似服務，也直到 AWS 才比較明確地把基礎設施服務化。

但使用者的需求差異很大。TCP/UDP、HTTP，再加上錯誤移轉、負載平衡、資料庫…還是有太多要選擇的東西，更別題還有大量的程式語言和軟體框架。距離我們想要的快速、通用還很遙遠。

所以這類平台就提供一層更高階的包裝，讓我們能用一個標準架構來部署各自的專案，藉此減少部署和維運產品的工作負擔。

因此我們可以從這個角度出發來看平台減少了我們哪些工作。

1. 部署容易

不論是從 Docker Hub 直接取得容器、從 Github/GitLab 取得專案編譯、或者提供 CLI 來快速部署，這些都是常見的需求，後兩者在現在是比較重要的。

當我們授權平台直接取得專案後，平台會自動辨識專案內容來執行編譯或打包，這樣最後可以用統一的方法部署。這部份技術可以參考容器化和 K8S，這邊我們就不詳述了。現在 AI 蓬勃發展，大量專案被開發出來，平台拿到專案就能直接部署上線，自然非常方便，省時又省力。

至於 CLI 嘛，以前是工程師專屬的工具，因為它在 shell 層運作，能貼合工程師的需求和習慣。走到現在，如果不使用特定的 MCP，CLI 就是讓 AI 幫你管理伺服器的好工具。
當然，大部分的 CLI 也是透過 HTTP 送出請求的，所以 AI 也可以直接操作對應的 API 來管理部署。

2. 網路設定方便

現在每個服務都上雲，一個伺服器怎麼能不需要網路，這樣就會產生很多工作。 Domain, SSL, Proxy, Load-Balance 隨便舉就有很多，那平台會提供哪些功能呢？

一樣照我們原本的目標：一組輕便，簡易且通用的伺服器框架。
從這個角度思考，我們只需要 Domain 跟 SSL 產品就可以通了，前者甚至可以直接使用平台提供的 subdomain，後者使用 Let’s Encrypt 甚至不用錢。

至於其他需求就當作附加價值吧，不是必需品了。

3. 資料持久化

簡單說就是資料庫，從基本的關聯式資料庫的自動備份和還原，到非結構式資料的儲存方案，甚至是靜態檔案儲存。這些每一個都涉及效能、可用、隱私等議題，也因此有非常多眉眉角角的設定跟架構設定。

難道平台也會提供這類功能？

通常沒有！因為這些太昂貴了。儲存、計算、傳輸資料樣樣都要錢，成本太高，所以通常會把資料庫當成一種產品，讓你自己選擇部署，而平台只要針對性的提供一些基本的功能就夠了。

所以你會看到自動部署資料庫，並提供設定好的參數，同時依照你的口袋深度，給予不同的安全機制，自動備份、快速還原的快照、或是較高的計算能力等等。

又或者你會看到專門的平台提供這類服務，等於是把資料庫這一層再抽出去包裝成服務，例如 Supabase

4. 稽核

我們需要日誌來了解產品的運作狀況，不論是使用效能、產品安全、訪問稽核，都可以從日誌的狀況獲取。如果能提供可視化或方便的過濾功能就很好了。至於一些大型產品需要的 Dashboard，抱歉，這通常不是平台的主要客群需求，但你依然可以從 API 取得資訊來建立更詳細的視覺化管理。

減少成本

減少平台成本，連帶著可以讓售價跟著降。較低的價格也更能吸引使用者。

然而平台真正的吸引力，應該來自上一節那些穩定、豐富又方便的功能，但使用者通常第一眼看的還是售價頁面。

我們已經知道這類平台通常是架設於基礎設施的服務之上，那麼成本就受限於提供基礎設施的廠商，而熟能詳的就是 AWS。

通常平台會跟這類廠商直接購買較大的用量，藉此拿到較低的價格來壓低成本。加上採用容器化、共用運算資源的方式，充分利用所有資源。

舉個比較好理解的案例，如果你的專案需要 2 vCPU + 2.5G memory，在 AWS 你只能租到 2 vCPU + 4G memory，多出來的記憶體就浪費掉了。
（簡單理解就好，實務上還是要保留一定資源來應對突波流量和系統運作需求等等）

如果有一個使用者用的資源跟你不同，或者他的產品尖峰時間與你錯開，你們的資源利用就會互補，能充分用掉同一台機器上的資源。

成本就這樣一點一點省出來，最後算出一個平均用量，用來計算訂閱制的價格。

以此，對一般用量的使用者來說，用平台通常會比較便宜；對用量大的企業來說，每次部署所省下的時間和精力都可以少好幾個人天，還是划算的。

當然，平台前期可能願意虧（少）損（賺），進一步壓低使用者的費用，藉此吸引更多的使用者進入。而大量的使用者進入訂閱，而訂閱費用不只讓平台的現金流穩定，還更有底氣向基礎設施供應商購買更大量的運算資源來壓低成本，藉此補平前期虧損。

那問題是什麼？

就跟二房東的概念類似（最近很常聽到這個形容詞）
房租會受到大房東影響，所以不少平台都會自己再養一套基礎設施，來穩定價格。

雖然 Zeabur 產品還太年輕，經營的時間和量體都不足，缺乏足夠的應變能力，只能硬扛基礎設施漲價的風波。又因為接連調整售價，影響使用者的消費信心，有可能陷入惡性循環。

即使 Zeabur 允許使用者自購的運算資源，只用平台的管理服務，但管理服務本身也有營運成本。

此外，有不少人在 Threads 上回報問題，都會有專門的工程師負責解答或協助設定。這點在當時是很不錯的做法，但站在產品維運的角度，需要工程師的介入，這是不是某種程度也反映出系統的穩定度不夠呢？

那我們該怎麼選擇

首先 Zeabur 作為平台服務來說，功能是很齊全的，而且客服的處理速度很快。加上大量的中文文件輔助，對於新手來說，我非常建議從這邊入手。

但對於已經有經驗的開發者來說，我會建議專注在自己的專案上，盡量降低產品遷移的難度。當平台出狀況時，就能順利遷移到其他平台。

而如果產品的用量很大，例如可以吃滿多台伺服器，或者有很高的可用性產品，需要多台 replica 之類的，那通常回到 AWS 之類的基礎設施服務，使用其提供的 Saving Plan 或 Spot 來壓低成本，會是比較彈性的做法。

不過雲端架構設計，本身也是設計的一環，在產品前提各自不相同的情況下，怎麼找出最優解還是需要一些經驗和判斷。盡可能列出詳細的資訊交由 AI 做分析，尋找合適的專業人員進一步規劃和維護，通常會有更好的結果。

最後，提供一份簡易的數據分析，我盡量拉到同樣的單位，這樣方便比較

項目（單位）	Railway	Zeabur	AWS EC2
CPU（每 vCPU·時）	$0.0278（$20 / 月）	免費（2024/11 起不計）	t3.medium 整台 $0.0416 / 時
Memory（每 GB·時）	$0.0139（$10 / 月）	$0.015（約 $10.8 / 月）	含於整台，不單獨計
Inbound（每 GB）	免費	免費	免費
Outbound（每 GB）	$0.10	$0.10	$0.09（每月前 100GB 免費）
Storage（每 GB·月）	$0.15	$0.20	EBS gp3 $0.08
IP（每月）	內含	共享，未單列	Elastic IP $3.6
LB（每月）	內含	內含	ALB 約 $18 起（另計用量）

為了更好理解，我們把一個情境套進去算。

假設一個小產品，後端和資料庫各一台，每台都是 2 vCPU + 4G memory，資料庫再掛 10 GB 的儲存空間，不開負載平衡，這樣跑滿一個月（以 720 小時計算）。
因為三者的流量傳輸價格差不多，我們跳過它，這樣月費大概是：

Railway：CPU 和記憶體都要算錢，一個月約 $161.6。
Zeabur：CPU 不計費，只算記憶體，一個月約 $88.4。
AWS EC2：兩台 t3.medium 按整台計價，再加一個對外 IP，一個月約 $64.3。

同樣的東西，在不考慮免費額度和訂閱方案限制的情況下，平台的確貴了不少。不過 AWS 本身還有很多零碎的費用藏在細節裡，加上一些限制可能還是需要進階服務的輔助，例如貴死人的負載平衡。實際用起來，Zeabur 還是有很大的優勢。何況 Zeabur 有 Taiwan Region，這點 Railway 大輸。

當然 AWS 有 Saving Plan 與 Spot 可以進一步大量減少運算成本，只是通常需要產品有一定的用量才適合，詳細可以開專題來說，再說要超過字數了。

簡單做個結論，我會建議如果被價格調整影響，的確可以參考看看其他平台的功能性價比。但如果是前期產品用量不高，找個 VPS 用用，或者找外包分享他們的共用資源即可，不要輕易自己上 AWS / GCP 等基礎設施自架，把精力留在打磨產品上會更適合。

篇幅有限，原本想要詳細介紹平台應該具有功能的，刪刪改改之後要下一篇了，這次就當個導讀吧。
下一篇，會著重在 AI 時代的需求來切入，找出值得我們為此挑選平台的功能。