<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Vendor-Lock-In on Tarragon</title><link>https://tarrragon.github.io/blog/tags/vendor-lock-in/</link><description>Recent content in Vendor-Lock-In on Tarragon</description><generator>Hugo -- gohugo.io</generator><language>zh-TW</language><copyright>Tarragon (CC BY 4.0)</copyright><lastBuildDate>Fri, 03 Jul 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://tarrragon.github.io/blog/tags/vendor-lock-in/index.xml" rel="self" type="application/rss+xml"/><item><title>自架 vs 雲端的成本交叉點</title><link>https://tarrragon.github.io/blog/devops/08-cost-management/self-hosted-vs-cloud/</link><pubDate>Fri, 03 Jul 2026 00:00:00 +0000</pubDate><guid>https://tarrragon.github.io/blog/devops/08-cost-management/self-hosted-vs-cloud/</guid><description>&lt;p>自架跟雲端/商業方案的成本抉擇，關鍵在兩條成本曲線的交叉點。這兩條曲線的形狀根本不同：自架的成本成長得很慢（sublinear）——處理 1 個用戶跟 100 個用戶的基礎設施成本差異極小，只在規模拉大、維運人力上來時才逐步爬升；商業或雲端託管的成本隨規模線性上升——按事件量、用戶數、或主機數計費，業務成長直接乘上費用。小規模時自架的平坦曲線更低，某個規模之後商業的規模經濟勝出，交叉點就在兩條線相交的地方。&lt;/p>
&lt;h2 id="兩條曲線為什麼形狀不同">兩條曲線為什麼形狀不同&lt;/h2>
&lt;p>自架成本成長慢，是因為它的主要成本是一次性的建置與相對固定的維運，跟用量幾乎脫鉤（真正隨規模上升的是維運人力，不是機器）。一套自己跑的監控、資料處理，處理的事件多一個數量級，機器可能只需要多開一點，但架構、維護的成本不變。商業成本線性，是因為它的計量單位（事件、主機、席位）直接綁在業務成長上——用戶翻倍、事件翻倍，帳單就翻倍。這是計量模式跟業務規模綁定的結果，不是單價高低的問題。&lt;/p>
&lt;p>交叉點的位置沒有硬數字，是經驗估算：使用者數少（約百人以下）時，自架的總成本（建置加維護加硬體）通常低於商業方案的年費；規模大（約千人以上）時，商業的規模經濟與省下的人力勝出。中間是一段灰色地帶，取決於功能需求與團隊能力。給幾個錨點感受量級——典型商業監控方案年費約數百美元起、按規模往上，不少方案有免費額度（如某些錯誤追蹤方案免費到每月數千個事件、某些分析方案免費到每月百萬級事件），小規模可以零成本起步。這些免費額度耗盡後轉按量付費，帳單就開始爬那條線性曲線。&lt;/p>
&lt;h2 id="交叉點不是一個點是一段光譜">交叉點不是一個點，是一段光譜&lt;/h2>
&lt;p>把選擇當成「自架」跟「用雲端」的二元，會錯過中間大片的漸進選項。真實的選擇是一道光譜，差別在「哪些層自己管、哪些交給平台」：完全用商業 SaaS（只管埋點、其餘全外包）、用 BaaS 加 serverless（自己寫邏輯、平台管伺服器與資料庫維運）、用 PaaS（跑自己的程式碼、平台管佈署與 TLS）、到完全自架（全部自己管）。從左到右，自己扛的越來越多、單位成本越來越低、但人力投入越來越大。&lt;/p>
&lt;p>這道光譜讓「交叉點」變成「可漸進遷移的區間」。小規模時用商業方案的免費額度零成本起步、同時保留自訂的彈性；規模成長、成本爬升到某個點，再往光譜的自架端遷移。關鍵是遷移方向的成本不對稱——從自架換到商業容易（改個埋點端點就好）、從商業換回自架難（要從零建起整套收集、儲存、儀表板）。所以起步時選哪個位置，要把「將來往哪個方向遷」算進去。&lt;/p>
&lt;h2 id="不在帳單上的成本">不在帳單上的成本&lt;/h2>
&lt;p>自架的帳單很便宜，但它的主要成本不在帳單上——在人力。自架系統的功能上限等於團隊願意投入的工程量：基本的查詢自己寫幾行就有，但儀表板、告警、進階分析，每一個功能都是數週到數月的開發；規模大了之後，高可用、擴容、備份的維運又是持續的人力。這些是自架真正的成本，只比雲端帳單而忽略人力，會嚴重低估自架的代價——這跟 &lt;a href="https://tarrragon.github.io/blog/devops/05-capacity-planning/cost-model/" data-link-title="成本模型" data-link-desc="把容量規劃的資源翻成錢時，釐清 on-demand、reserved、spot 三種計費模式的取捨、怎麼算單位請求成本、以及過度與不足配置各自的經濟代價">模組五 成本模型&lt;/a> 講的「自建與託管人力差 3 到 10 倍」是同一件事。&lt;/p>
&lt;p>商業方案的隱藏成本則在 lock-in 與合規。深度用了某個 vendor 的私有 schema 與功能，遷出的代價很高——這是前面說的方向不對稱。合規則可能把天平推向自架、且與規模無關：資料落地（data residency）的要求下，自架能完全控制資料位置，商業方案只有部分供應商提供特定區域、免費方案的區域選擇還可能受限。一個有嚴格資料落地要求的服務，可能不管規模多小都得自架。算自架划不划算，要把人力、lock-in、合規這三筆帳單外的成本一起算進去，才是真實的交叉點。&lt;/p>
&lt;h2 id="下一步路由">下一步路由&lt;/h2>
&lt;ul>
&lt;li>自建與託管的人力成本差、承諾模式怎麼配 → &lt;a href="https://tarrragon.github.io/blog/devops/05-capacity-planning/cost-model/" data-link-title="成本模型" data-link-desc="把容量規劃的資源翻成錢時，釐清 on-demand、reserved、spot 三種計費模式的取捨、怎麼算單位請求成本、以及過度與不足配置各自的經濟代價">模組五 成本模型&lt;/a>&lt;/li>
&lt;li>計費的維度與隱藏成本（egress、lock-in）→ &lt;a href="https://tarrragon.github.io/blog/devops/08-cost-management/billing-models/" data-link-title="計費模式理解" data-link-desc="看懂雲端帳單怎麼生成時，先認清收費的維度、on-demand/reserved/savings plan/spot 的承諾差異、以及 egress 這類最常被忽略的隱藏成本">計費模式理解&lt;/a>&lt;/li>
&lt;li>監控 SaaS 的部署光譜與自架對照 → &lt;a href="https://tarrragon.github.io/blog/monitoring/06-commercial-comparison/" data-link-title="模組六：商業方案對照" data-link-desc="Sentry / Crashlytics / Datadog RUM / Mixpanel — 自架 vs 商業的功能和成本取捨">monitoring 商業方案比較&lt;/a>&lt;/li>
&lt;/ul></description><content:encoded><![CDATA[<p>自架跟雲端/商業方案的成本抉擇，關鍵在兩條成本曲線的交叉點。這兩條曲線的形狀根本不同：自架的成本成長得很慢（sublinear）——處理 1 個用戶跟 100 個用戶的基礎設施成本差異極小，只在規模拉大、維運人力上來時才逐步爬升；商業或雲端託管的成本隨規模線性上升——按事件量、用戶數、或主機數計費，業務成長直接乘上費用。小規模時自架的平坦曲線更低，某個規模之後商業的規模經濟勝出，交叉點就在兩條線相交的地方。</p>
<h2 id="兩條曲線為什麼形狀不同">兩條曲線為什麼形狀不同</h2>
<p>自架成本成長慢，是因為它的主要成本是一次性的建置與相對固定的維運，跟用量幾乎脫鉤（真正隨規模上升的是維運人力，不是機器）。一套自己跑的監控、資料處理，處理的事件多一個數量級，機器可能只需要多開一點，但架構、維護的成本不變。商業成本線性，是因為它的計量單位（事件、主機、席位）直接綁在業務成長上——用戶翻倍、事件翻倍，帳單就翻倍。這是計量模式跟業務規模綁定的結果，不是單價高低的問題。</p>
<p>交叉點的位置沒有硬數字，是經驗估算：使用者數少（約百人以下）時，自架的總成本（建置加維護加硬體）通常低於商業方案的年費；規模大（約千人以上）時，商業的規模經濟與省下的人力勝出。中間是一段灰色地帶，取決於功能需求與團隊能力。給幾個錨點感受量級——典型商業監控方案年費約數百美元起、按規模往上，不少方案有免費額度（如某些錯誤追蹤方案免費到每月數千個事件、某些分析方案免費到每月百萬級事件），小規模可以零成本起步。這些免費額度耗盡後轉按量付費，帳單就開始爬那條線性曲線。</p>
<h2 id="交叉點不是一個點是一段光譜">交叉點不是一個點，是一段光譜</h2>
<p>把選擇當成「自架」跟「用雲端」的二元，會錯過中間大片的漸進選項。真實的選擇是一道光譜，差別在「哪些層自己管、哪些交給平台」：完全用商業 SaaS（只管埋點、其餘全外包）、用 BaaS 加 serverless（自己寫邏輯、平台管伺服器與資料庫維運）、用 PaaS（跑自己的程式碼、平台管佈署與 TLS）、到完全自架（全部自己管）。從左到右，自己扛的越來越多、單位成本越來越低、但人力投入越來越大。</p>
<p>這道光譜讓「交叉點」變成「可漸進遷移的區間」。小規模時用商業方案的免費額度零成本起步、同時保留自訂的彈性；規模成長、成本爬升到某個點，再往光譜的自架端遷移。關鍵是遷移方向的成本不對稱——從自架換到商業容易（改個埋點端點就好）、從商業換回自架難（要從零建起整套收集、儲存、儀表板）。所以起步時選哪個位置，要把「將來往哪個方向遷」算進去。</p>
<h2 id="不在帳單上的成本">不在帳單上的成本</h2>
<p>自架的帳單很便宜，但它的主要成本不在帳單上——在人力。自架系統的功能上限等於團隊願意投入的工程量：基本的查詢自己寫幾行就有，但儀表板、告警、進階分析，每一個功能都是數週到數月的開發；規模大了之後，高可用、擴容、備份的維運又是持續的人力。這些是自架真正的成本，只比雲端帳單而忽略人力，會嚴重低估自架的代價——這跟 <a href="/blog/devops/05-capacity-planning/cost-model/" data-link-title="成本模型" data-link-desc="把容量規劃的資源翻成錢時，釐清 on-demand、reserved、spot 三種計費模式的取捨、怎麼算單位請求成本、以及過度與不足配置各自的經濟代價">模組五 成本模型</a> 講的「自建與託管人力差 3 到 10 倍」是同一件事。</p>
<p>商業方案的隱藏成本則在 lock-in 與合規。深度用了某個 vendor 的私有 schema 與功能，遷出的代價很高——這是前面說的方向不對稱。合規則可能把天平推向自架、且與規模無關：資料落地（data residency）的要求下，自架能完全控制資料位置，商業方案只有部分供應商提供特定區域、免費方案的區域選擇還可能受限。一個有嚴格資料落地要求的服務，可能不管規模多小都得自架。算自架划不划算，要把人力、lock-in、合規這三筆帳單外的成本一起算進去，才是真實的交叉點。</p>
<h2 id="下一步路由">下一步路由</h2>
<ul>
<li>自建與託管的人力成本差、承諾模式怎麼配 → <a href="/blog/devops/05-capacity-planning/cost-model/" data-link-title="成本模型" data-link-desc="把容量規劃的資源翻成錢時，釐清 on-demand、reserved、spot 三種計費模式的取捨、怎麼算單位請求成本、以及過度與不足配置各自的經濟代價">模組五 成本模型</a></li>
<li>計費的維度與隱藏成本（egress、lock-in）→ <a href="/blog/devops/08-cost-management/billing-models/" data-link-title="計費模式理解" data-link-desc="看懂雲端帳單怎麼生成時，先認清收費的維度、on-demand/reserved/savings plan/spot 的承諾差異、以及 egress 這類最常被忽略的隱藏成本">計費模式理解</a></li>
<li>監控 SaaS 的部署光譜與自架對照 → <a href="/blog/monitoring/06-commercial-comparison/" data-link-title="模組六：商業方案對照" data-link-desc="Sentry / Crashlytics / Datadog RUM / Mixpanel — 自架 vs 商業的功能和成本取捨">monitoring 商業方案比較</a></li>
</ul>
]]></content:encoded></item></channel></rss>