四个关键技术决策帮助企业避免云锁定这些旗舰服务与平台上的其他服务配合良好，但通常会限制与其他公共云的互操作性，从而导致云供应商锁定。拥抱锁定有其原因：它使公司能够提高生产力并更快地为用户提供价值。我们在Render正在构建一个跨多个公共云启动的新云平台，并计划添加本地工作负载，这对我们避免将自己锁定在一个提供商中至关重要。本文讨论了我们为避免锁定到一个云提供商并为混合云的未来做准备而做出的一些关键技术决策。图1：此图可视化了两个示例性技术堆栈。左边是没有云锁定的技术栈，右边是拥抱云锁定的技术栈。基础设施即代码如今，大多数软件公司都需要基础设施即代码(IaC)。它是任何技术堆栈的基石，一旦做出选择，就很难改变。热门选择包括AWSCloudFormation、Terraform、Pulumi、Chef和A??nsible。AWSCloudFormation仅适用于完全致力于使用AWS产品的公司。Terraform在许多组织中很受欢迎，但确实需要学习一种新的领域特定语言。如果您想使用一种您已经知道的语言，那么Pulumi（Node.js、Go、Python和.NETCore）、Chef(Ruby)或Ansible(Python)可能更合适。最后，我们使用了Terraform和Ansible，以寻求它们成熟的生态系统和广泛的云提供商支持。Ansible是我们用于配置机器映像的首选工具，而Terraform非常适合跨多个公共云配置基础设施组件和配置网络。配置和机密每个生产级应用程序都需要访问配置变量和机密，这些变量和机密最好存储在专用、加密且易于访问的位置。云提供商提供API驱动的产品，可以轻松安全地存储和访问数据：AWSSecretsManager、AWSSSMParameterStore和GoogleCloudSecretManager都是此类产品，使用户无需管理底层存储和加密。但是，通过API访问这些服务是基于IAM登录，不能跨云移植。我们的供应和机密管理解决方案必须让我们能够完全控制我们的数据输入，与所有主要的云提供商合作，并随着公司的发展轻松扩展。访问经过专业人士审查的源代码也很重要。Vault最终满足了我们的所有要求，另外一个好处是它相对容易设置和管理。服务编排Kubernetes可能过于复杂，但提供了有用的抽象来统一跨公共云和私有数据中心的服务器/容器编排。我们的团队之前接触过Kubernetes，尽管它有缺点，但由于其蓬勃发展的社区和发展速度，我们选择它而不是其他编排工具。我们早期的重点是尽快进入市场，因此我们决定使用托管Kubernetes产品。然而，由于我们每月处理数十亿个请求，我们的跨多个云的托管解决方案也遇到了多个限制和软件错误。最终，缺乏对控制平面的访问和可见性清楚地表明我们的初始设置不合时宜，我们需要管理我们自己的Kubernetes集群。同时，在所有集群中拥有相同的Kubernetes管理原语对我们来说很重要，这对于来自不同云提供商的托管Kubernetes当然是不可能的。Render推出法兰克福托管区是一个重要的里程碑——它不仅将Render变成了一个多区域、多云平台，而且还帮助我们从头开始构建管理Kubernetes的专业知识。我们似乎通过拥抱Kubernetes锁定来避免云锁定。但是我们的UX决策在这里起了很大作用：我们选择避免??成为另一个托管的Kubernetes平台，而是完全专注于使Render成为一个以UX为中心的平台，而不是将Kubernetes暴露给客户。这样，我们始终可以迁移到最适合我们用户需求的内部或第三方编排工具。消息队列向分布式系统添加新组件会导致复杂性急剧增加，这很快就会成为管理员的噩梦。消息队列通过为新服务提供一个单一的集成点来轻松地解决这个问题，以便与所有现有和未来的服务进行通信。公共云通过默认集成其专有队列服务来创建锁定。例如，Google提供了BigQuery和Pub/Sub之间的原生集成，而AWS让用户可以非常轻松地将SQS与Lambda、RDS、Redshift和其他AWS组件连接起来。我们的消息锁解决方案很简单：使用自托管的RedisPub/Sub和优秀的开源机器项目在Redis之上提供一个Golang队列抽象，如果需要的话可以在不更改应用程序代码的情况下换成另一个。OSS队列。我们的消息队列方法已经扩展到每天处理超过1亿个事件，而无需在将消息队列部署到新的云和区域时更改一行代码。原标题：TechniquestoAvoidCloudLock-in，作者：ShantanuJoshi
