云端开发是个坑！4 年后，我们又回到了本地环境 _云端开发

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

一些运行在 Kubernetes 中的复杂微服务架构是 CPU 和内存密集型的，在某些情况下编译或测试可能非常耗时且占用大量资源。然而大多数工程师的标准设备是笔记本电脑，有 CPU 和内存的限制，编译一次的时间估计够喝好几杯咖啡。

建立在云端的远程实例通常可以根据需要进行扩展，以适应对容量的额外需求，因此在容器化变革的基础上，一些企业开始不再那么依赖于本地开发环境。虽然近一两年有一些令人兴奋的远程方案，比如 GitHub Codespaces、AWS Workspaces 或其它使用云的标准解决方案，但在它们足够成熟和安全之前，很多企业早已选择了自建云端开发环境，Lyft 就是其中之一。

云端开发逐渐成为了坑
早在 2018 年，Lyft 的工程师就将一个大单体拆分成了一系列微服务。基于 Docker 容器的模块化开发环境最终转移到了云端。然而随着时间的推移，工程师、微服务和测试的数量的激增，他们的开发工具跟不上了。

实际上，Lyft 对综合开发环境的第一次重大投资始于 2015 年，当时的工程师人数为 100 名，大部分开发还是在一个单体架构上，只有少数用例是微服务，但预计到工程师和服务的数量会增长，所以他们认为迁移到容器是很有意义的。最初的计划是构建一个基于 Docker 的容器编配环境，工程师可以用它们做测试。它将在生产环境中使用多租户环境，相比以前的解决方案，可以更便宜、更快地进行伸缩。

2016 年初，Lyft 发布了一个本地开发环境，叫作 Devbox，是“盒子里的开发环境”的缩写，由一些管理本地虚拟机及其配置的工具组成，包括数据生成、包和镜像的下载和安装。开发人员只需要发出一个命令就可以构建一个可以处理请求的环境。

这些体验很棒，让工程师们第一次拥有了一种一致的、可重复的、简单跨多个服务开发方法，于是很快出现了共享这些环境的需求。Devbox 转向了云端，变成了 Onebox 。Onebox 本质上是一个运行在 EC2 实例上的 Devbox 环境。由于它的容量更大，下载镜像的速度更快，工程师们自然更喜欢它而不是 Devbox 。

文章插图

两种不同风格的开发环境

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

由于每个服务都有很深的交互树结构，实例可能需要很多的资源。可观察性工具不能跟上所有正在运行的环境，导致调试工作变得很困难。打比方说，不可能在数百个环境中运行相同的可观察性工具，当出现问题时，就很难查明确切原因。此外，工程师的认知负担显著增加，因为他们需要牢记整个系统，而不是专注于特定的组件。

根据 Lyft 的工程设计，工程师的代码变更过程可以分为“内部开发循环”和“外部开发循环” 。前者应该只需要几秒钟就能给出反馈，因为它只涉及修改代码和运行一些测试。后者可能需要更长的时间（至少 10 分钟），因为它涉及持续集成和代码评审。集成测试臃肿笨拙，花费一个小时是司空见惯的事情。并且 80% 以上的测试要么是不必要的，要么可以在短时间内重写并在没有外部依赖的情况下运行。测试失败还要花费数小时的调试时间，大多数还都是误报。

文章插图

另一方面，执行内部开发循环通常需要将代码更改同步到开发人员自己在 Onebox 的远程 VM 环境。考虑到 Onebox 环境的设置和启动速度很慢，再加上明显的不稳定性，工程师通常会依赖外部开发循环的 CI 测试来验证每个代码变更迭代。

一年前，将开发环境迁移到 Kubernetes 之后，工程资源的变化让大家不得不重新审视开发环境：维护基础设施以支持这些按需环境变得过于昂贵，而且只会随着时间的推移而恶化，所以需要对开发和测试微服务的方式进行更根本性的改变。

开发环境必须回到工程师的机器上
为了摆脱不断增长的烦恼和挫折，Lyft 将开发环境带回到工程师的笔记本电脑上，同时重新构建内部开发循环。

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