云开发环境是软件工程的未来吗？

某些运行的复杂的微服务架构是CPU和内存密集型，在某些情况下进行编译或测试可能是耗时且资源密集的。但是，大多数工程师的标准设备是具有CPU和记忆限制的笔记本电脑，并且一次编译的时间可能足以喝几杯咖啡。

通常可以根据需要对云上构建的远程实例进行缩放以满足额外的容量需求，因此基于容器化的变化，某些企业开始不再如此依赖本地开发环境。尽管过去一两年中有一些令人兴奋的远程解决方案，例如AWS或使用云的其他标准解决方案，但许多企业已经选择在它们成熟和安全之前构建自己的云开发环境，而Lyft就是其中之一。

云发展逐渐成为一个坑

早在2018年，Lyft工程师将大型单体分为一系列微服务。基于容器的模块化开发环境最终移至云中。但是，随着时间的流逝，工程师，微服务和测试的数量已经飙升，并且他们的开发工具未能跟上。

实际上，Lyft在2015年开始对综合开发环境的首次重大投资始于当时的100名工程师，大部分开发都使用了整体建筑，只有少数用用例就是微服务，但是预期会增加的工程师和服务的数量，因此他们认为它可以迁移到容器中。最初的计划是建立一个基于工程师可以用于测试的容器编排环境。它将在生产中使用多租户环境，并且比以前的解决方案可以更便宜，更快。

2016年初，Lyft发布了一个名为“框中开发环境”的本地开发环境，该环境由一些管理本地虚拟机及其配置的工具组成，包括数据生成，下载和安装软件包和图像。开发人员只需要发出命令即可构建可以处理请求的环境。

这些经验很棒，为工程师提供了跨多种服务的一致，可重复，简单的开发方法，并且需要迅速出现​​共享这些环境的需求。转向云层，它变成了。本质上是在EC2实例上运行的环境。由于它具有更大的容量和更快的镜子下载，因此工程师自然更喜欢它。

两种不同风格的开发环境

介绍和作为容器化的开发环境四年后，使用这些环境的工程师增加了十倍，微服务的数量一直在飙升，配置和启动实例变得越来越困难和耗时。

由于每个服务都有深层的交互式树结构，因此实例可能需要大量资源。可观察性工具不能跟上所有运行环境，从而使调试变得困难。例如，在数百个环境中运行相同的可观察性工具是不可能的，当出现问题时，很难找出原因。此外，工程师大大增加了认知负担，因为他们需要牢记整个系统，而不是专注于特定组件。

根据Lyft的工程设计，工程师的代码更改过程可以分为“内部开发环”和“外部开发环”。前者只需要几秒钟就能提供反馈，因为它仅涉及修改代码并运行一些测试。后者可能需要更长的时间（至少10分钟），因为它涉及连续集成和代码审查。集成测试肿又笨拙，花一个小时很常见。超过80％的测试要么是不必要的，也可以在短时间内重写并在没有外部依赖项的情况下运行。测试故障需要几个小时的调试时间，其中大多数是错误的警报。

另一方面，执行内部开发循环通常需要对开发人员自己的远程VM环境进行同步代码更改。鉴于环境的设置缓慢和启动速度，再加上明显的不稳定，工程师通常依靠外部开发环的CI测试来验证每个代码更改迭代。

一年前移动开发环境之后，工程资源的变化迫使每个人都重新审视了开发环境：维持基础设施以支持这些按需环境变得太昂贵了，并且只会随着时间的推移而恶化，因此需要更多的基本变化来开发和测试微服务。

开发环境必须返回工程师的机器

为了摆脱日益增长的烦恼和挫折，Lyft将开发环境带回了工程师的笔记本电脑，同时重建了内部开发周期。

在容器中运行代码不是免费的抽象，因此他们决定在不使用容器或虚拟机的情况下在隔离环境中运行服务代码。

在Lyft中，大多数后端服务都是用或GO语言开发的，而前端服务则以节点开发：

一些专业服务（例如数据存储）也在本地运行，通常使用容器。数据存储开始使用服务团队维护的脚本来加载新数据。

因此，在本地启动服务需要多个步骤。手动执行它们既乏味又容易出错。 Lyft使用倾斜来协调服务生命周期及其环境，避免手动执行所有步骤。每个服务都有一个描述本地运行服务所需步骤的步骤。当工程师修改IDE中的代码时，运行服务还将重新加载本身，进一步缩短内部开发循环。

除了运行服务外，您还需要与服务进行交互。由于Lyft使用不同的传输格式，例如GRPC，JSON /HTTP和 / /HTTP，因此向服务请求并不那么简单。工程师使用LYFT开发的工具将请求发送到本地服务。该工具可以与服务的IDL集成，因此可以利用该工具的自动完成功能。

最终结果

自从在整个公司中推广此工具以来，Lyft工程师都收到了很好的反馈。

开发人员喜欢在没有任何远程环境的情况下在笔记本电脑和IDE中运行测试的能力。创建新的环境通常需要大约一个小时，但是现在笔记本电脑环境总是可以进行测试，只需几分钟即可使用倾斜来启动本地服务。

“我们还观察到开发人员之间的行为转移，因为他们花了更多时间专注于测试他们的服务。在测试本地服务时，用户可以直接向服务API发送请求，而不是通过移动应用程序与公共API进行交谈。这增加了开发人员对服务API的熟悉并在错误的情况下缩小调试。”

并且让用户在笔记本电脑上单独运行服务意味着真正减少所需的总计算资源。 “虽然成本不是该项目的主要驱动力，但我们最终不再为每个开发人员支付AWS实例而节省了很多钱。”

通常，由于开发环境，开发人员尤其难以忍受地停滞正常工作。不良的开发环境会严重影响每个人的生产力，并且一个好的本地开发环境使开发人员可以运行和测试代码，而不会破坏共享环境或干扰面向客户的环境的风险。而且，它通常是低成本的，它依赖已经支付的资产，并且比基于云的环境更有效，更便宜。

此外，这意味着他们还密切关注完全遥远的开发环境，以查看它们在成熟时是否适合它们。

参考链接：