別被避免鎖定的觀念給鎖住了

架構師的主要目標之一是 建立選項。這些選項使系統具有耐變性，因此我們可以推遲決策，直到有更多資訊可用或對不可預見的事件做出反應。鎖定則相反：它使從一個解決方案切換到另一個解決方案變得困難。因此，許多架構師可能會認為鎖定是他們的死敵，而他們自己是 IT 系統自由世界的守護者，其中可以隨意更換和互連組件。

但架構很少那麼簡單 - 這是個權衡取捨的業務。有經驗的架構師知道，鎖定背後還有更多的事，而不能只是宣稱必須避免鎖定。鎖定有許多面向，甚至可能是偏好的解決方案。因此，讓我們進入 架構師電梯，來更仔細地檢視鎖定。

開源-混合-多雲端 == 無鎖定？

我們現今部署軟體的平台正變得越來越強大 - 現代的雲端平台不僅能告訴我們 我們的照片顯示的是小狗還是瑪芬，它們還能編譯我們的程式碼、部署它、設定必要的基礎架構，並儲存我們的資料。

這種極大的便利性和生產力提升也帶來了鎖定的一種全新形式。混合式/多雲端設定，這似乎吸引了許多架構師的注意，是一個你必須思考的鎖定類型範例。假設你有一個你想要部署到雲端的應用程式。這很容易做到，但從架構師的觀點來看，有許多選擇，甚至更多權衡取捨，特別是與鎖定相關的。

你可能想要在容器中部署你的應用程式。這聽起來不錯，但你應該使用 AWS 的彈性容器服務 (ECS) 來執行它們嗎？畢竟，它是亞馬遜雲端的專有技術。偏好 Kubernetes 嗎？它是開放原始碼，並執行在多數環境中，包括內部部署。問題解決了嗎？還沒有 - 現在你被綁定在 Kubernetes 上 - 想想那些寶貴的 YAML 檔案！因此你用另一種鎖定取代了另一種鎖定，不是嗎？如果你使用受管理的 Kubernetes 服務，例如 Google 的 GKE 或 Amazon 的 EKS，你可能也會被綁定在 Kubernetes 的特定版本和專有擴充功能上。

如果您需要軟體在公司內部執行，您也可以選擇 AWS Outposts，因此您有一些選項。但這再次是專有的。它與 VMWare 整合，您可能已經鎖定在其中，所以它真的有差別嗎？Google 的等價產品，新推出的 Anthos，是由開源元件建構的，但仍然是專有產品：您可以將應用程式移至不同的雲端 - 只要您持續使用 Anthos。現在這就是鎖定的定義，不是嗎？

或者，如果您將部署自動化與應用程式執行時間整齊地分開，這是否讓切換基礎架構變得相當容易，減少所有鎖定的影響？嘿，甚至有跨平台基礎架構即程式碼工具。這些難道不應該讓這些問題完全消失嗎？

對於您的儲存需求，AWS S3 如何？其他雲端供應商提供與 S3 相容的 API，因此 S3 是否可以被視為多雲端相容且無鎖定，即使它是專有的？您也可以將所有資料存取包裝在抽象層的背後，並因此將任何相依性本地化。這是一個好主意嗎？

看起來避免鎖定並不容易，甚至可能讓您被鎖定在嘗試逃離它的過程中。為了強調雲端架構仍然很有趣，我推遲到 Simon Wardley 對混合雲的看法。

鎖定的層面

電梯建築師（那些上下搭乘 建築電梯 的人）看到灰色地帶，而許多人只看到黑白。在思考系統設計時，他們了解到鎖定或耦合等常見屬性並非二進位的。兩個系統並非只是耦合或解耦，就像您並非只是鎖定在產品中或沒有鎖定一樣。這兩個屬性都有許多細微差別。例如，鎖定會分解成許多面向

• 供應商鎖定：這是 IT 人員在提到「鎖定」時通常會想到的那種。它描述從一個供應商切換到競爭對手的難度。例如，如果您從 Siebel CRM 遷移到 SalesForce CRM 或從 IBM DB2 資料庫遷移到 Oracle 資料庫會讓您花費一大筆錢，您就是「被鎖定」。這種類型的鎖定很常見，因為供應商通常（或多或少明顯地）從中受益。這種鎖定包括商業安排，例如長期授權和支援協議，讓您當時獲得授權費用的折扣。
• 產品鎖定：相關但不同的情況是鎖定在某個產品。當從某個供應商的產品遷移到另一個供應商的產品時，你通常會同時更換供應商和產品，因此這兩者很容易混淆。開源產品可以避免供應商鎖定，但並未消除產品鎖定：如果你使用 Kubernetes 或 Cassandra，你肯定會鎖定在特定產品的 API、組態和功能中。如果你在專業（尤其是企業）環境中工作，你還需要商業支援，這將再次將你鎖定在供應商合約中 - 詳見上方。大量的自訂、整合點和專有擴充套件都是產品鎖定的形式：它們會讓切換到其他產品變得困難，即使它是開源的。
• 版本鎖定：除了鎖定在某個產品中，你甚至可能鎖定在特定版本中。如果版本升級會損壞你已建立的現有自訂和擴充套件，則升級版本可能會很昂貴（SAP，有人嗎？）。其他版本升級基本上要求你改寫你的應用程式 - AngularJS 與 Angular 2 就是個例子。更糟的是，版本鎖定會蔓延：某個產品版本可能需要某個（通常過時的）作業系統版本，依此類推，這會讓任何遷移嘗試變成一項無聊的任務。當供應商決定淘汰你的版本或終止整個產品線時，你會特別強烈感受到這種鎖定：你必須在沒有支援或進行重大修改之間做出選擇。而且事情可能會變得更糟，例如，如果在你的舊版本中發現了重大的安全性漏洞，但沒有提供修補程式。
• 架構鎖定：你可能也鎖定在特定類型的架構中。例如，當你廣泛使用 Kubernetes 時，你可能會建立公開 API 並可作為容器部署的小型服務。如果你想要遷移到無伺服器架構，你會希望將服務的粒度更改為更接近單一功能，外化狀態管理，利用事件架構，可能還有更多事項。此類變更並非微不足道，而是意味著對你的應用程式架構進行重大修改。
• 平台鎖定：產品鎖定的一種特殊形式是鎖定在平台中，尤其是雲端平台。此類平台不僅執行你的應用程式，還可能持有你的使用者帳戶和相關的存取權限、安全性政策、基礎設施分段和更多面向。它們還提供應用程式層級的服務，例如儲存或機器學習服務，這些服務通常是專有的。遠離這些服務似乎是減少平台鎖定的方法，但它會否定最初轉移到雲端的主要動機之一。非軟體人員稱此為發現自己處於兩難境地。
• 技能鎖定：隨著你的開發人員越來越熟悉某種類型的產品或架構，你將會有技能鎖定：你將需要時間重新訓練（或聘用）開發人員以使用不同的產品或技術。由於技能可用性是當今 IT 商店的主要限制之一，因此這種鎖定非常真實。一些利基企業產品的開發人員供應特別有限，導致你的開發人員成本上升。對於採用自訂語言或具有諷刺意味的是「僅組態」/ 無程式碼架構的產品，這種效應特別明顯。
• 法規鎖定：您可能會因法規原因（例如合規性）而鎖定在特定解決方案中。例如，如果您的資料中心位於您的國家/地區以外，您可能無法將資料移轉到其他雲端供應商的資料中心。即使您的系統在雲端執行得很好，您的軟體供應商的授權也可能不允許您將系統移轉到雲端。如果您決定這麼做，您將違反授權條款。法規層面滲透到工程的各個方面，遠超過我們一般所假設的：您的小型引擎飛機很可能搭載的是 1970 年代設計的引擎，而且會燃燒含鉛量很高的燃料：新的引擎設計面臨很高的法規責任。
• 思維鎖定：最微妙，但也是最危險的鎖定類型，會影響您的思維。在與特定供應商和架構合作後，您可能會在決策中吸收假設，這可能會導致您拒絕其他選項。例如，您可能會拒絕擴充式架構，因為它們無法線性擴充（當硬體加倍時，您無法獲得兩倍的效能）。雖然在技術上是正確的，但這種思維方式忽略了可擴充性（而非效率）才是主要驅動力。或者，您可能會對短版次週期感到不滿，因為您觀察到頻繁的變更導致更多缺陷。而且您肯定聽過編碼很昂貴、耗時且容易出錯，所以您最好透過組態來完成所有事情。

總之，鎖定遠非全有或全無的事務，因此瞭解不同的類型可以幫助您做出更明智的架構決策。此清單也揭穿了常見的迷思，例如使用開放原始碼軟體可以神奇地消除鎖定。開放原始碼可以減少供應商鎖定，但大多數其他類型的鎖定仍然存在。這並不表示開放原始碼很糟糕，但它並非鎖定的萬靈丹。

使用模型做出更好的決策

經驗豐富的架構師不僅能看到更多灰色地帶，還能實踐良好的決策紀律。這很重要，因為我們做決策的能力遠比我們通常願意相信的還要差 - 如果您有任何疑問，請快速閱讀 卡尼曼的快思慢想。

改善決策制定最有效的方法之一是使用模型。即使是簡單的模型，或特別是簡單的模型，在改善決策制定方面都出奇地有效

簡單但引人入勝的模型是偉大科學家的標誌，但過度精緻和過度參數化通常是平庸的標誌。

-- 喬治·艾德華·帕克斯·巴克斯

這就是為什麼您不應該嘲笑管理顧問如此喜愛的著名的二乘二矩陣。正如我們很快就會發現的，它是其中最簡單且因此最有效的模型之一。

關於模型，有一個第二個重要的觀點：一個普遍的信念告訴我們，面對不確定性，您幾乎必須「憑感覺行事」- 畢竟，一切都在變化。實際上恰恰相反：當我們必須處理許多相互依賴性、高度不確定性和小機率時，我們通常糟糕的決策制定只會變得更糟。因此，這是模型最能幫助為我們的決策制定帶來急需的結構和紀律的地方。決定是否以及在何種程度上接受鎖定完全屬於此類別，因此讓我們使用一些模型。

鎖定作為一個二乘二矩陣

一個簡單的模型可以幫助我們擺脫「鎖定＝糟糕」的汙名。首先，我們必須了解不鎖定任何事物是很困難的，因此一定程度的鎖定是不可避免的。其次，如果我們獲得相應的回報，例如競爭產品沒有提供的獨特功能或效用，我們可能會欣然接受一定程度的鎖定。

讓我們在一個非常簡單的模型中表達這些因素 - 一個二乘二矩陣

矩陣概述了我們沿著以下軸線的選擇

• 切換成本（又稱「鎖定」）：我們轉移到另一個解決方案的難度有多大？
• 獨特效用：與其他方案相比，我們從解決方案中獲得多少收益？

現在我們可以考慮這四個象限中的每一個

• 一次性：沒有獨特效用且易於替換的組件，是我們最不必擔心的組件。我們可以讓它們保持原樣，或者如果我們遇到任何問題，我們可以輕鬆地替換它們。對於平凡的事物來說，這不是一個壞地方。例如，大多數開發人員 IDE（EMACS 可能是一個顯著的例外！）都屬於這一類別：隨意混合搭配，不要過於依賴它們。您所有照片和其他個人資料的雲端儲存也已將您的智慧型手機設備大量移至這個方框，但稍後會詳細說明。
• 接受鎖定：對角線上的組件會將您鎖定在特定產品或供應商中，但作為回報，它們會為您提供獨特的功能或效用。雖然我們通常更喜歡較少的鎖定，但這種權衡可能是可以接受的。您可以使用 Google Cloud BigQuery 或 AWS Bare Metal Instances 等產品，清楚地知道您已被鎖定，並根據您獲得的回報做出明智的決定。對於小型應用程式，您也可以愉快地使用原生 AWS 服務，因為不太可能進行遷移，而且開發和運作工作量的減少非常受歡迎。
• 注意：最不理想的方框是將你鎖住，但並未提供許多獨特功能。你的傳統關係資料庫可能會落入此方框中 - 使用任何專有資料庫真的會增加你的收益嗎？並不會。然而，轉移可能會耗費許多精力，因此你最好確定不太可能需要這麼做。如果你為發射到外太空的嵌入式系統選擇特定硬體，這很可能沒問題 - 轉移的機率相當低。
• 理想：最好的東西是能提供你獨特功能，但同時又容易轉換。雖然這聽起來像是理想的目標，你必須承認這個方框有點矛盾：如果某個解決方案能提供你獨特的功能，根據定義，競爭產品將不會具備該功能，這會讓轉移變得困難。S3 可能適合這個類別的範例 - 多個雲端供應商已採用相同的 API，這使得轉換到例如 GCP 相對容易。儘管如此，每個實作在區域性、效能等方面都有一些獨特優勢。為了保護這種跨差異化產品的可攜性，我們不允許 API 受到著作權或專利的保護非常重要。

雖然這個模型很簡單，但將你的軟體（或許還有硬體）元件放入這個矩陣中是一項有價值的練習。它不僅能視覺化你的曝險，還能將你的決策傳達給各種利害關係人。

對於四個象限的日常範例，你可能決定使用以下項目，它們會提供你不同程度的鎖定和功能（從右上開始逆時針）

• 你心愛的iPhone將你鎖定在供應商生態系統中，但它也提供獨特功能，因此你很可能可以接受這種可接受的鎖定。
• 你的行動供應商合約將你鎖定在單一網路中，但並未真正提供比其他網路更多的功能。最好採取注意。
• 你的手機充電器有標準接頭。遺憾的是，許多 iPhone 沒有，但幸運的是，轉接線纜仍然讓這個小工具成為可拋棄式。
• 你的許多應用程式，例如傳訊，會提供你功能，例如讓你的朋友在上面，但它們仍設計成便於切換，例如使用手機的聯絡人清單。那是理想的。

在獨特效用方面，謹慎的一句話：每個供應商都會給你一些形式的獨特功能，這就是他們區別於別人的方式。然而，這裡重要的是，該功能是否能轉化為對你和你的組織來說具體且獨特的價值。例如，一些雲端供應商在其令人驚嘆的全球網路中執行十億用戶服務。這令人印象深刻且獨特，但不太可能是對平均企業的效用，而平均企業很樂於服務 100 萬名客戶，並且可能僅限於在單一國家/地區經營業務。有些人仍然在限速嚴格的小國家/地區購買法拉利，所以顯然並非所有決策都完全合理，但法拉利可能以雲端平台無法做到的方式為你提供效用。

鎖定的實際成本

由於這個簡單的矩陣非常有用，讓我們再做一個。先前的矩陣將切換成本視為單一元素（或維度）。一位好的架構師可以看出它會分解成兩個維度

該矩陣區分了進行切換的成本和你有（或想要）進行切換的可能性。可能性低且成本低的因素不應讓你太困擾，而另一端，即切換成本高且切換機率高的因素則不好，應加以解決。在另一個對角線上，你正在冒險選擇那些會讓你付出代價，但不太可能發生的選項，這就是你想要購買一些保險的地方，例如透過限制變更範圍或增加你的維護預算。你也可以接受風險，你實際上需要從 Oracle 遷移到 DB2，或反之亦然的頻率有多高？最後，如果切換很可能但很便宜，你便達到了敏捷性，你擁抱變更並設計你的系統以執行低成本。奇怪的是，儘管許多小的變更迅速累積，但這個象限通常比左上角得到較少的關注。這是我們糟糕的決策制定在起作用：不太可能的戲劇得到更多關注，因為萬一！

在討論鎖定的可能性時，你會想要考慮各種讓你轉換的場景：供應商可能會倒閉、漲價，或者可能不再能夠支援你的規模或功能需求。有趣的是，減少鎖定的慾望有時會以談判工具的形式出現：在協商更新授權時，你可以暗示你的供應商，你設計你的系統，讓轉換離開他們的產品是實際且便宜的。這可能有助於你協商較低的價格，因為你已經傳達你的 BATNA - 你的 最佳替代協商協議 很低。這是一種不打算真正使用的架構選項 - 是一種威懾，有點像冷戰中的武器庫存。你或許能夠偽造它，而實際上並未減少鎖定，但最好在供應商虛張聲勢時，你是個好的撲克玩家，例如在飲水機旁與你的開發人員聊天。

降低鎖定：執行價格

再次從一開始引入我們的 選項類比，如果避免鎖定會給你選項，那麼轉換的成本就是選項的行權價格：這是你執行選項所支付的金額。你想要達成的轉換成本越低，選項的價值就越高，因此價格也越高。雖然我們夢想讓所有系統都在「綠色方塊」中，且轉換成本極小，但必要的投資可能實際上無法得到回報。

例如，許多架構師贊成不要被鎖定在資料庫供應商或雲端供應商中。然而，轉換的可能性有多高？也許 5%，甚至更低？將轉換成本從假設的 50,000 美元（半手動遷移）降低到接近零，將會花費你多少成本？可能遠遠超過你可以預期節省的 2,500 美元（50,000 美元 x 5%）。因此，將轉換成本降到最低並非唯一目標，而且很容易導致過度投資。這相當於過度保險：支付巨額保費將自負額降至零，可能會讓你安心，但這通常不是最經濟，因此也不是合理的選擇。

一個最終模型（不是矩陣）可以幫助你決定你應該投資多少來降低轉換成本。下圖顯示你的負債，定義為轉換成本乘以發生的可能性，與你必須進行的前期投資相關（藍線）。

透過投資選擇權，你可以肯定地降低你的負債，無論是透過降低切換的可能性或降低執行成本。例如，使用像 Hibernate 的物件關係對應 (ORM) 架構是一個小投資，可以降低資料庫供應商鎖定。你也可以建立一個元語言，翻譯成每個資料庫供應商的原生儲存程序語法。它將允許你充分利用資料庫效能而不用依賴，但它將需要大量前期工作，以應付相對不太可能發生的情況。

因此，有趣的函數是紅線，它將前期投資加入潛在負債。那是你的總成本，也是你應該最小化的東西。在大多數情況下，隨著前期投資的增加，你將朝向最佳範圍前進。額外投資於降低鎖定實際上會導致更高的總成本。原因很簡單：投資報酬率會遞減，特別是對於機率小的切換。如果我們讓我們的架構變得非常靈活，我們很可能會陷入這種過度投資的區域。Yagni（你不需要它）的人可能會瞄準光譜的另一端 - 就像經常發生的，訣竅是找到快樂的媒介。

避免鎖定的總成本

現在我們對被鎖定的成本和潛在報酬有了很好的掌握，我們需要仔細了解避免鎖定的總成本。在先前的模型中，我們假設避免鎖定是一個簡單的成本。然而，實際上，這個成本可以分解成幾個組成部分

• 努力：這是以人時計算的額外工作。如果我們選擇在 Kubernetes 上部署容器以降低雲端供應商鎖定，此項目將包括學習新工具、撰寫 Docker 檔案、設定 Kubernetes 等工作。
• 費用：這是額外的現金支出，例如產品授權、聘請外部供應商或參加 KubeCon。
• 使用不足：這種間接成本會發生，因為避免鎖定通常會禁止你使用供應商特定的功能。結果是，你從你使用的軟體中獲得的效用較少。這反過來可能意味著你需要付出更多努力來建立遺失的功能，或者它可能會導致你的產品出現弱點。
• 複雜性：複雜性是方程式中的核心元素，而且經常被忽略。許多降低鎖定的努力會引入額外的抽象層：JDBC、容器、常見 API。雖然所有有用的工具，例如層會增加另一個變動的部分，增加整體系統複雜性。這反過來會增加新團隊成員的學習工作和系統性錯誤的機會。
• 新的鎖定：避免一種鎖定通常會以另一種鎖定為代價。例如，你可能會選擇避免 AWS CloudFormation 而改用支援多個雲端供應商的 Hashicorp 的 Terraform 或 Pulumi。但是，現在你被鎖定在另一個額外供應商的產品中，並且需要找出這是否對你來說沒問題。

在計算避免鎖定的成本時，架構師應快速瀏覽此清單以避免盲點。此外，請注意，避免鎖定的嘗試可能會出現漏洞，很像有漏洞的抽象。例如，Terraform 是一個很好的工具，但其腳本使用許多特定於供應商的建構。因此，實作細節會「外洩」，導致從一個雲端切換到另一個雲端的成本絕對不為零。

重新整合

有了這麼多理論，讓我們來看幾個具體的例子。

思考速度的架構

可能會覺得可以花很多時間思考鎖定。有些人甚至可能會將我們的做法視為「學術」，我始終無法將這個字視為負面，因為我們大多數人都是從那裡獲得教育的。儘管如此，舊式的黑白架構方法是不是更簡單，而且可能更有效率？

實際上，思考真的會發生得非常快速。瀏覽本文中顯示的所有模型可能真的只需要幾分鐘，而且會產生有據可查的決策。除了紙張或白板之外，不需要任何花俏的工具。快速架構思考的關鍵要素只是專注的能力。

將其與準備精緻投影片簡報的努力相比較，這些簡報是為數週前就已排定的冗長導向委員會會議而準備的，而且通常不會有具備實際專業知識來做出明智決策的人員出席。

電梯架構師寧願花時間思考，也不願等待會議。