【51CTO.com快譯】每家云提供商都有吸引公司和開發者在其平臺上構建產品的主打服務。這些旗艦服務可與平臺上的其他服務很好地協作，但常常限制與其他公共云的互操作性，從而導致云供應商鎖定。擁抱鎖定有其理由：它可以使公司提高生產力，并更快地為用戶提供價值。

我們Render正在構建一個跨多個公共云啟動的新云平臺，計劃增加本地工作負載，這對于我們避免將自己被某一家提供商鎖定至關重要。本文討論了我們做出的一些關鍵技術決策，以避免自己被某一家云提供商鎖定，并為混合云未來做好準備。

圖1：該圖直觀顯示了兩種示例性的技術堆棧。左邊是沒有云鎖定的技術堆棧，右邊是擁抱云鎖定的技術堆棧。

基礎架構即代碼

如今，大多數軟件公司都需要基礎架構即代碼(IaC)。它是所有技術堆棧的基石，一旦做出了選擇，很難進行更改。大受歡迎的選擇包括AWS CloudFormation、Terraform、Pulumi、Chef和Ansible。

AWS CloudFormation僅適用于全力使用AWS產品的公司。Terraform頗受許多組織的歡迎，但確實需要學習一種新的特定領域語言。如果您想使用一種已經知道的語言，那么Pulumi(Node.js、Go、Python和.NET核心)、Chef(Ruby)或Ansible(Python)可能更適合。最終，我們使用了Terraform和Ansible，沖著其成熟的生態系統和廣泛的云提供商支持而去。Ansible是我們配置機器映像的首選工具，Terraform在提供基礎架構組件和在多個公共云上配置網絡時效果很好。

配置和秘密

每個生產級應用程序都需要訪問配置變量和秘密(secret)，它們最好存儲在專用、加密且易于訪問的位置。云提供商提供了API驅動的產品，易于安全地存儲和訪問該數據：AWS Secrets Manager、AWS SSM Parameter Store和Google Cloud Secret Manager都是這類產品，用戶不必管理底層的存儲和加密。然而，通過API訪問這些服務基于IAM登錄信息，IAM登錄信息無法跨云移植。

我們的配置和秘密管理解決方案必須讓我們可以全面控制自己的數據進、適用于各大云提供商，并隨著公司的發展易于擴展。訪問已經過專業人員審核的源代碼也至關重要。保險柜(vault)最終滿足了我們所有的要求，還有一個好處是，設置和管理比較容易。

服務編排

Kubernetes可能過于復雜，但是提供了有用的抽象，可以跨公共云和私有數據中心統一服務器/容器編排。我們的團隊之前接觸過Kubernetes，盡管存在缺點，但由于其迅速壯大的社區和發展步伐，我們還是選擇了它而不是其他編排工具。

我們早期的重點是盡快進入市場，因此我們決定使用托管的Kubernetes產品。然而，隨著我們每個月要處理數十億個請求，我們還遇到了跨多個云的托管解決方案存在的多重限制和軟件錯誤。最終，對控制平面缺乏訪問和可見性清楚地表明，我們最初的設置已跟不上發展的需求，我們需要管理自己的Kubernetes集群。同時，跨所有集群都有同樣的Kubernetes管理基元對我們來說很重要，如果使用來自不同云提供商的托管Kubernetes，這當然不可能實現。Render推出法蘭克福托管區域是一大里程碑——它不僅將Render變成了一個多區域多云平臺，還幫助我們從頭開始積累管理Kubernetes方面的專業知識。

我們似乎通過擁抱Kubernetes鎖定避免了云鎖定。但我們在UX方面的決定在這里幫了大忙：我們選擇避免成為另一個托管的Kubernetes平臺，而是完全專注于使Render成為一個注重UX的平臺，并不向客戶公開Kubernetes。這么一來，我們隨時可以遷移到最適合用戶需求的內部或第三方編排工具。

消息隊列

向分布式系統添加新組件導致復雜性急劇提高，可能很快成為管理者的噩夢。消息隊列通過為新服務提供單一集成點、與所有現有和將來的服務進行通信，為輕松解決該問題提供了一種方案。公共云通過默認與其專有隊列服務集成來形成鎖定。比如說，谷歌提供BigQuery和Pub/Sub之間的原生集成，而AWS讓用戶極容易將SQS與Lambda、RDS、Redshift及其他AWS組件聯系起來。

我們解決消息傳遞鎖定的方法很簡單：使用自托管的Redis Pub / Sub和出色的開源機器項目在Redis上提供Golang隊列抽象，需要的話，可以在不更改應用程序代碼的情況下將其換成另一個OSS隊列。我們的消息隊列方法已擴展到每天處理1億多個事件的規模，將消息隊列部署到新的云和區域時，沒必要更改一行代碼。

原文標題：Techniques to Avoid Cloud Lock-in，作者：Shantanu Joshi

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】