如何避免云服务锁定

一则或许对你有用的小广告

欢迎加入小哈的星球 ,你将获得:专属的项目实战 / 1v1 提问 / Java 学习路线 / 学习打卡 / 每月赠书 / 社群讨论

  • 新项目:《从零手撸:仿小红书(微服务架构)》 正在持续爆肝中,基于 Spring Cloud Alibaba + Spring Boot 3.x + JDK 17...点击查看项目介绍 ;
  • 《从零手撸:前后端分离博客项目(全栈开发)》 2 期已完结,演示链接: http://116.62.199.48/ ;

截止目前, 星球 内专栏累计输出 63w+ 字,讲解图 2808+ 张,还在持续爆肝中.. 后续还会上新更多项目,目标是将 Java 领域典型的项目都整一波,如秒杀系统, 在线商城, IM 即时通讯,权限管理,Spring Cloud Alibaba 微服务等等,已有 2200+ 小伙伴加入学习 ,欢迎点击围观

对于软件产品,确定产品/市场契合点、进入市场,然后扩展以满足业务需求,这些都是需要快速发生的事情。时间就是金钱,我们现在考虑每天需要进行数十次部署。

正如我经常提到的,优化您的时间并专注于您的核心产品对于您的业务和客户来说至关重要。您可以查看我最近关于 团队生产力 云服务的 帖子,了解更多相关细节。

随着对快速行动的需求增加,许多团队开始使用云来快速启动大型基础设施。但这些云服务——尤其是最新的服务迭代,如 AWS Lambda 或构建在云之上的弹性容器服务——可能导致许多团队回避的一定程度的锁定。

锁定是什么样的

在讨论这个话题时,我听到的最大担忧是可能会锁定到特定的提供商。在这种基础设施中,我看到了三种不同的锁定场景。

移动基础设施需要付出努力

当您更换提供者时,总会涉及将您锁定在当前提供者中的工作。即使使用基于标准工具和框架构建的基础架构,您也必须完成传输数据、 更改 DNS 和广泛测试新设置的过程。更好的工具可以帮助简化这一过程,但并不能完全消除痛苦。

在 Codeship,到目前为止,我们已经取得了巨大的成功,因为 Packer 是我们构建基础设施的主要驱动力。此外,我们尽量接近我们使用的任何工具的标准,以免过于拘泥于特定服务的细节。

代码级锁定

当托管服务要求您针对其专有 API 进行编码并在其专有平台之上构建时,就会出现代码级锁定。

Google App Engine 是深度代码级锁定的一个例子。它要求您以针对他们的系统量身定制的非常具体的方式构建您的应用程序。这可以为您带来重大优势,因为它非常紧密地集成到基础架构中,但您也完全依赖于该平台。

例如, Heroku 采取了相反的方式,构建了一个使用人们想要构建的标准框架(例如,Rails、Django 等)的平台。它不像 Google App Engine 那样优化和自动化,但它给他们的客户一种可以随时离开 Heroku 的感觉。

对于很多团队来说,深度锁定风险太大。主要基础设施提供商做出的任何决定都可能对他们的公司产生严重影响,甚至可能产生负面影响,而且没有任何方法可以迅速摆脱供应商。虽然离开特定的提供商需要做很多工作,但至少需要有这个选项。

“代码级锁定对许多团队来说是有风险的,因为对 1 个供应商的依赖性在增加。”

架构锁定

当服务提供商的细节迫使您采用其他提供商不支持或最低限度支持的架构风格时,就会发生架构锁定。即使可能没有任何或很少的代码级锁定,也可能发生架构锁定。

具有最少代码锁定但主要架构锁定的服务示例是 AWS Lambda 。在 Lambda 的第一次迭代中,您编写 Node.js 函数并通过 API 调用这些函数,或者它们在 S3、Kinesis 或 DynamoDB 中的特定事件上被调用。

对于任何足够复杂的基础设施,这可能会导致数十或数百个非常小的功能,这些功能本身并不复杂,或者在代码级别上有主要的锁定。但是您不能使用这些节点功能并在另一台服务器或托管服务提供商上运行它们。您需要围绕它们构建自己的系统,这意味着高度的架构锁定。

从好的方面来说,有很多我们根本不需要再处理的基础设施。事件在您的基础架构中的某处触发,您的功能将自动执行和扩展。

Heroku、AWS 和其他云提供商已经看到了这种不切实际的情况,并且正在减少代码级锁定,同时提供创建架构锁定的新服务。

为您的团队评估锁定场景

第一个锁定类别——移动基础设施需要付出努力——很难避免,但可以缩小到可管理的规模。

你绝对应该尝试在你的平台中引入工具,至少可以让切换提供商成为可能。 Packer 等工具和定期将数据备份和恢复到不同提供商的工作流程是一些保障措施,可以帮助您确保能够脱离主要托管服务提供商。这些保护措施对于小型团队来说可能看起来过多,但是一旦您转到中型工程团队,它们就是必需的。

代码级别和架构锁定的可接受权衡更难以定义。

“你的团队需要讨论哪种锁定场景是可以接受的。”

我更喜欢架构锁定到代码级别。通过构建基于开源技术的小型服务,可以更轻松地规避架构锁定。即使您可能希望保留托管服务提供商的某些服务,您也可以将其他服务从该提供商那里移走。这使您能够决定基础架构的哪一部分最适合哪个提供商。

不过,这些提供商必须基于开源技术。否则,您将陷入代码级和架构锁定。

因此,首先要评估特定提供商强迫您进入的代码级锁定程度。抽象提供者的 API 以便将来可以在代码级别轻松切换到另一个提供者是否容易?

接下来,分析您是否由于架构限制而被锁定在以特定方式构建。您能否通过使用协同工作的更简单的服务来减少架构锁定?将来从特定供应商转移出来最困难的部分是什么?

结论

由每个团队决定哪些锁定场景是一个很好的权衡。基于您可以在各种供应商上使用的技术构建的面向微服务的架构可以抵消一些权衡(例如,像 Rails 或 Node 这样的框架)。您可以一开始就在服务之上构建,然后将基础架构的一部分移动到其他地方,以便在将来获得更多控制权。

在评论中让我们了解您在基础架构中锁定的策略和经验。

相关文章