雲端供應商綁定(Vendor Lock-in)沒有你想的那麼可怕|專家論點【黃婉中】

作者:黃婉中(雲端架構師)

在 Azure 工作這幾年,我常在會議室聽到客戶提到「避免 Vendor Lock-in」。但觀察久了,你會發現這句話通常不是架構師在擔心的,而是採購或決策者在說的。

所謂的「抽象層」,其實就像是為了在不同雲端間切換而設計的「萬用轉接頭」。(圖/AI生成)
所謂的「抽象層」,其實就像是為了在不同雲端間切換而設計的「萬用轉接頭」。(圖/AI生成)

他們真正的意思,其實不是怕技術上搬不走,而是想保留一個「我隨時可以離開」的姿態。這是一種商業談判:客戶會在單一雲端環境穩定使用三到五年,等量跑大了、折扣拿夠了,在合約快到期時,再拿著這些使用量去跟另一家談。

就像我們手機門號約滿了,不一定是因為收訊不好才想轉電信商,單純只是想看看別家能不能給出更優惠的續約條件。在雲端市場,這種採購策略其實每天都在發生。

更多科技工作請上科技專區:https://techplus.1111.com.tw/
科技社群討論區:https://pei.com.tw/feed/c/tech-plus

為了追求「隨時能搬走」所付出的代價

我曾經遇到一個客戶,為了保持「跨雲可攜性」,花了三年在做一套中立的架構。

他們規定所有的東西都要跑在 Kubernetes (AKS) 上,完全不碰 Azure 的原生服務,像是 Azure Functions、Service Bus 或 Cosmos DB。

所謂的「抽象層」,其實就像是為了在不同雲端間切換而設計的「萬用轉接頭」。但為了讓這個轉接頭相容,你必須放棄每家雲端最強的獨特功能,導致工程師大半的時間都在維修這個轉接頭,而不是在開發產品。

三年後,他們的 CTO 來找我,決定放棄這套架構,改為大量採用原生服務。因為他們發現,如果直接用雲端長好的功能,部署週期能大幅縮短

這就是最弔詭的地方:為了防範「萬一要搬家」的風險,他們付出了三年研發緩慢的「確定損失」。

我們常擔心被廠商綁架,但冷靜想想,雲端大廠倒閉或惡意漲價的機率,跟我們自己公司因為產品出太慢而倒閉的機率,哪個比較高?至少在過去十年,雲端市場整體定價都是下降的。

有時讓團隊痛苦的,是為了追求靈活性而過度複雜的架構設計。

Egress Cost 不是供應商的陷阱

很多人把跨雲傳輸的成本當成鎖定的風險,其實有點誤會了。

不論你選哪一家雲,只要有資料傳輸,就會產生 Egress Cost。就算你在同一個 Azure 帳號下,跨區域 (Region) 傳輸一樣會計費。所以,成本高低跟「你選哪家雲」其實關係不大,反而是跟「你的資料流怎麼設計」有直接關係。

如果架構設計得不好,製造了大量不必要的跨區傳輸,那這就是病因,而帳單只是症狀。

監管合規的現實:服務完整性與法規

每次談到「為了合規所以要多雲」,其實背後有個假設:每家雲在各個地區的服務都一樣好用。但現實完全不是這樣。

以中國市場為例,雲端環境與全球是分開的。Azure 由世紀互聯營運,AWS 則由本地合作夥伴營運,兩者的架構邏輯相似,帳號與全球版不互通。受限於當地的營運環境,中國區的服務項目通常會比全球版少一些。而 GCP 則選擇了不同的市場策略,目前在中國境內不提供直接的雲端服務。

在美國聯邦政府市場,情況又不一樣。Azure Government 和 AWS GovCloud 都是實體與邏輯完全獨立的專屬雲端平台。而 GCP 則主要透過 Assured Workloads 等技術控管手段來滿足合規要求。

所以,你的業務在哪、面對什麼法規,決定了你的選項。

如果供應商在當地的服務支援並不符合你的特定業務需求,那麼談論多雲架構的靈活性,在實務上就會面臨很大的挑戰。

「深度整合」帶來的競爭優勢

其實,如果能把 Azure 的生態系用深、用透,這反而是你的優勢。當服務之間能無縫串接,開發節奏會快很多。

統一的 IAM 權限、監控和成本管理,能省下許多維運心力。如果你的對手更敢用這些工具,讓產品迭代得更快,那他雖然「被鎖定」了,卻能跑得更快。

我常跟客戶分享:先想辦法讓產品成功。等到公司真的大到需要擔心 Vendor Lock-in 的時候,你到時絕對有足夠的資源去處理它。在那之前,專注在業務的成長吧。

重點回顧

  • 「避免 Vendor Lock-in」是談判桌上的語言:客戶三到五年跳一次雲,是為了用離開的可能性,換回議價的籌碼。
  • 為了保持可攜性付出的確定損失,可能大於被 Lock-in 傷害的不確定風險
  • Egress Cost 跟選哪家雲無關,跟資料流怎麼設計才有關
  • 監管合規的真正問題不是「要不要多雲」,而是你需要的那家雲,在你需要的地區,服務完不完整、法規合不合規。

💡延伸閱讀:我如何轉職成為雲端解決方案架構師

延伸閱讀:當 ETL 不再需要工程師:Databricks、Fabric、Snowflake 開戰,資料人的下一站在哪?|專家論點【黃婉中】

 

Loading

在 Google News 上追蹤我們

發佈留言

Back to top button