每家云提供商都有吸引公司和开发者在其平台上构建产品的主打服务。这些旗舰服务可与平台上的其他服务很好地协作，但常常限制与其他公共云的互操作性，从而导致云供应商锁定。拥抱锁定有其理由：它可以使公司提高生产力，并更快地为用户提供价值。

我们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