【51CTO.com快譯】每家云提供商都有吸引公司和開發(fā)者在其平臺(tái)上構(gòu)建產(chǎn)品的主打服務(wù)。這些旗艦服務(wù)可與平臺(tái)上的其他服務(wù)很好地協(xié)作，但常常限制與其他公共云的互操作性，從而導(dǎo)致云供應(yīng)商鎖定。擁抱鎖定有其理由：它可以使公司提高生產(chǎn)力，并更快地為用戶提供價(jià)值。

我們Render正在構(gòu)建一個(gè)跨多個(gè)公共云啟動(dòng)的新云平臺(tái)，計(jì)劃增加本地工作負(fù)載，這對(duì)于我們避免將自己被某一家提供商鎖定至關(guān)重要。本文討論了我們做出的一些關(guān)鍵技術(shù)決策，以避免自己被某一家云提供商鎖定，并為混合云未來(lái)做好準(zhǔn)備。

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

基礎(chǔ)架構(gòu)即代碼

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

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

配置和秘密

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

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

服務(wù)編排

Kubernetes可能過(guò)于復(fù)雜，但是提供了有用的抽象，可以跨公共云和私有數(shù)據(jù)中心統(tǒng)一服務(wù)器/容器編排。我們的團(tuán)隊(duì)之前接觸過(guò)Kubernetes，盡管存在缺點(diǎn)，但由于其迅速壯大的社區(qū)和發(fā)展步伐，我們還是選擇了它而不是其他編排工具。

我們?cè)缙诘闹攸c(diǎn)是盡快進(jìn)入市場(chǎng)，因此我們決定使用托管的Kubernetes產(chǎn)品。然而，隨著我們每個(gè)月要處理數(shù)十億個(gè)請(qǐng)求，我們還遇到了跨多個(gè)云的托管解決方案存在的多重限制和軟件錯(cuò)誤。最終，對(duì)控制平面缺乏訪問(wèn)和可見性清楚地表明，我們最初的設(shè)置已跟不上發(fā)展的需求，我們需要管理自己的Kubernetes集群。同時(shí)，跨所有集群都有同樣的Kubernetes管理基元對(duì)我們來(lái)說(shuō)很重要，如果使用來(lái)自不同云提供商的托管Kubernetes，這當(dāng)然不可能實(shí)現(xiàn)。Render推出法蘭克福托管區(qū)域是一大里程碑——它不僅將Render變成了一個(gè)多區(qū)域多云平臺(tái)，還幫助我們從頭開始積累管理Kubernetes方面的專業(yè)知識(shí)。

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

消息隊(duì)列

向分布式系統(tǒng)添加新組件導(dǎo)致復(fù)雜性急劇提高，可能很快成為管理者的噩夢(mèng)。消息隊(duì)列通過(guò)為新服務(wù)提供單一集成點(diǎn)、與所有現(xiàn)有和將來(lái)的服務(wù)進(jìn)行通信，為輕松解決該問(wèn)題提供了一種方案。公共云通過(guò)默認(rèn)與其專有隊(duì)列服務(wù)集成來(lái)形成鎖定。比如說(shuō)，谷歌提供BigQuery和Pub/Sub之間的原生集成，而AWS讓用戶極容易將SQS與Lambda、RDS、Redshift及其他AWS組件聯(lián)系起來(lái)。

我們解決消息傳遞鎖定的方法很簡(jiǎn)單：使用自托管的Redis Pub / Sub和出色的開源機(jī)器項(xiàng)目在Redis上提供Golang隊(duì)列抽象，需要的話，可以在不更改應(yīng)用程序代碼的情況下將其換成另一個(gè)OSS隊(duì)列。我們的消息隊(duì)列方法已擴(kuò)展到每天處理1億多個(gè)事件的規(guī)模，將消息隊(duì)列部署到新的云和區(qū)域時(shí)，沒(méi)必要更改一行代碼。

原文標(biāo)題：Techniques to Avoid Cloud Lock-in，作者：Shantanu Joshi

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】