我负责开发工具团队已经有十年了。在这段时间里，我见证了Vagrant的兴起和衰落，以及Docker和其他众多构建工具的引入。我还记得大多数开发人员桌子下有两台台式机的时候，我帮助他们大规模迁移到Mac笔记本电脑上。我还帮助开发了用于AWS上自助计算的内部平台。所有这些工具都旨在将生产环境与开发环境更加接近，并提供易于配置和扩展本地环境的功能。然而，它们都没有做到。
自从加入 Palantir 以来，我与许多不同的开发体验负责人交谈过。结果发现有一些共同的主题。
-
**许多开发人员的笔记本电脑性能不佳。**这可能是由于安全工具调优不当、本地进程过重，以及Chrome占用大量资源等原因。
-
**大多数公司在Mac vs. Linux vs. Windows的争论中陷入困境。**在大多数情况下，IT团队需要为这三种操作系统提供支持。总会有一些工具或库的工作方式有所不同，从而导致问题。然后，像Mac的M1芯片这样的东西出现了，一切都乱了套。
-
**前端开发人员与UX设计师合作困难。**特别是在这个远程工作的世界中，大多数公司没有良好的设置来帮助设计师和开发人员合作。许多公司仍然依赖截图或短视频来演示新的UI组件 - 真是太糟糕了。
-
**高性能笔记本电脑价格昂贵。**如果你有一个计算密集型的应用程序，你可能需要为每个开发人员支付4000美元，并且每次他们喝醉了把笔记本电脑丢在酒吧里都要再花4000美元。
但是，老实说，与这个相比，这些都不重要：
- **大多数工程师对他们的本地环境并不满意。**老实说：你觉得你的笔记本电脑使用起来很愉快吗？你的笔记本电脑是否妨碍了你？还是给予了你力量？
如果你非常喜欢你的笔记本电脑，从来没有不得不关闭大部分应用程序才能让你的 Teams 会议不卡顿，那么这篇博文不适合你。请离开。
远程开发意味着将所有构建和测试过程都放在远程机器上，而你的笔记本电脑只是一个浏览器或轻量级客户端。
远程开发显著提高开发人员的生产力
远程开发的核心论点是，通过将开发工作负载移至远程机器，您能够比分发新的笔记本电脑给开发团队更快地移动、配置和扩展远程机器。如果远程机器针对您的用例进行了优化，它可以做到以下几点。
-
**提高构建和测试速度：**底层的虚拟机可以根据每个项目的需求进行扩展和优化。在我们的实验中，我们将构建时间从9分钟缩短到2分钟。
-
**减少延迟：**通过将远程环境放置在正确的区域，可以显著减少与基础设施或云API的距离。对于在美国东部基础设施上工作的澳大利亚开发人员来说，这将某些过程的时间缩短了10倍。
-
**消除耗时的设置步骤：**每个代码库都有可以自动化的设置步骤，在控制工作区时更容易实现。在具有较旧代码库的大型组织中，这一点尤为明显。只需自动安装一次，就可以节省所有人的时间。
-
**多个环境。**当对库进行重大更新时，您可以并行启动第二个工作区以进行此用例。这样可以保持环境修改的隔离，使您能够继续针对原始代码库编写代码。
我第一次遇到这个模型是在一个工程师那里，他在远程虚拟机上使用了code-server（注意57k的星标）。他的问题是，他无法检出和构建一个大型代码库，因为他的笔记本电脑被安全工具拖垮了，导致他的IDE崩溃。我当时被震惊了，但我意识到这个模型不会扩展。虚拟机的成本可能非常高，每个开发人员运行一个或多个环境是不合理的。开发人员只需要在工作时间运行他们的环境，而这种类型的使用对于Kubernetes来说非常适合。
将远程开发环境部署为Kubernetes pod解决了我的成本和设置问题。我可以控制执行环境、基础镜像和安全实践，并且可以利用成本优势，在开发人员开始和结束工作日时扩展和缩减计算能力。
如上图所示，每个开发人员都有自己的持久卷，但底层的容器可以是临时的。由于存储成本只占总计算成本的一小部分，这使得开发人员在工作日运行非常强大的容器，而公司在晚上和周末只需花费几分钱。
我真的相信本地开发会消失吗？
好吧，好吧 - 我并不真的相信它会消失，但并不是因为我有一个非常有说服力的论点。像谷歌和Facebook这样的大型组织多年来一直在使用远程开发模型，但使这种体验变得出色的开源工具花了一些时间才赶上。
最合理的反对意见是，远程开发对于网络不稳定的地区的开发人员来说并不理想。虽然这在今天是事实，但是随着Starlink和ASTS等努力，我相信我们离全球可访问的互联网只有几年的时间。
第二个最合理的反对意见是关于JetBrains套件的远程开发体验。JetBrains在2021年发布了[Gateway](https://www.jetbrains.com/remote-development/gateway/)来解决这些问题。不幸的是，JetBrains的Gateway一开始并不完善，我不会推荐它给全职使用IntelliJ或Webstorm的用户。然而，它在过去一年中取得了重大进展，我预计在1-2年内，用户将发现它与本地开发相当。
坦率地说，主要的犹豫是对于全职开发人员来说，是否相信基于浏览器的IDE是可以接受的。它肯定会有延迟、难以使用、不可靠或其他令人不愉快的地方，对吗？
这就是CoderOSS的优势所在。这是一种免费的方式，让您自己亲自体验远程开发的体验。自己尝试是最好的方法。
我建立了一个易于使用的仓库，作为演示路径，展示了远程基于Kubernetes的Visual Studio Code是什么样子。我选择使用谷歌的托管Kubernetes服务，因为他们提供300美元的信用额度，而且GKE Autopilot非常简单易用。
Coder安装说明：
-
创建一个Google Cloud账号，在该项目中创建一个项目，并使用editor权限在该项目中创建一个服务账号。
-
Fork我的仓库，并使用spacelift.io或等效工具进行设置。
-
使用上面的项目ID设置GOOGLE_CREDENTIALS和TF_VAR_project。
-
运行并应用Terraform。
整个设置过程应该不到10分钟，但如果您对Google Cloud不熟悉，可能需要更长一点的时间。
Coder设置说明：
-
导航到负载均衡器的IP地址（Google Cloud / Kubernetes Engine / Services & Ingress）。
-
创建初始用户名和密码。
-
转到Templates / Kubernetes / Create Workspace，并给工作区命名。
-
三分钟内，您应该会看到这个：
- 点击‘code-server'应该会在新的浏览器标签中打开运行在远程系统上的VSCode。
不知道你怎么想，但第一次看到它的时候，我觉得这太神奇了。我习惯了Windows RDP或VNC的世界，使用浏览器作为我的全职IDE似乎是个噱头。但是看到它真正运行起来后，我就被吸引了。
作为一个多年来领导开发体验团队的人，也是一个虔诚的DevOps信徒（至少是根据Phoenix Project所描述的DevOps），我可以说，尽管优化公司的开发工作空间很重要，但这可能不是您最重要的问题。如果以下任何问题是您的主要问题之一，那么远程开发值得探索。
适合远程开发的问题
-
长时间的构建、执行或测试时间（>5分钟）通常受到计算、内存、磁盘、网络、延迟甚至操作系统的限制。远程开发模型可以调整所有这些因素，并且可以根据具体情况进行调整。
-
修补旧代码可能需要很长时间，如果工程师必须设置他们的本地工作站以与历史版本、遗留代码或很少接触的代码库一起工作。如果将环境封装在容器中，设置就不再是手动的，而是仅受容器启动时间的限制。此外，像Coder这样的工具支持每个开发人员同时启动多个环境，使他们能够为热修复而启动专用环境，而不会干扰他们当前的工作。
-
**保护源代码（即离线）**在处理法规（例如ITAR）、金融系统或安全关键系统时是必要的。许多这些组织努力实现完全离线以防止源代码泄漏。与维护远程开发笔记本电脑相比，维护远程开发容器要容易得多。
适合远程开发的开发类型
-
前端开发由于增加了计算/内存容量，可以显著提高开发效率，而且VSCode（前端开发最流行的IDE）与远程开发非常配合，因为它支持coder/code-server和通过SSH进行远程后端开发。此外，Coder支持远程开发URL，使开发人员能够与设计师在实际产品上进行协作，而不是通过GitHub PR中的截图。
-
内核或任何跨操作系统开发可以得到改善，因为您正在运行与您尝试开发的操作系统相同的IDE。Coder的OSS模型不限于Kubernetes，您也可以提供虚拟机。
-
离线网络是一个很好的用例，因为您不必花费太多时间来调整工作站。网络外的工程团队可以创建导入内部网络的基础镜像。这对于银行、医疗保健或军事用例非常有用。
远程开发正在迅速取代本地开发，而Kubernetes模型似乎是最具吸引力的版本。一个工程团队可以轻松地将其团队容器的内存容量翻倍，但将他们的笔记本电脑内存翻倍则过于昂贵。无论您尝试优化代码，最终您往往受制于Chrome或占用资源的安全工具。
Kubernetes远程开发模型鼓励对开发要求进行全面封装，这对于那些必须处理历史版本或遗留代码的公司来说带来了巨大的回报。Kubernetes模型还支持水平和垂直扩展，使您的开发人员永远不会因为“性能”而效率低下。最后，您的财务团队会感谢您提供更便宜的笔记本电脑。
虽然远程开发长期以来一直是谷歌和Facebook等软件巨头的常见做法，但Coder OSS已经打开了大门，使其对任何规模的公司都变得易于使用。如果您按照我仓库中的说明操作，您应该能够在30分钟内亲自看到这一点。
