如何选择云开发环境

资深工程师 David Eastman 梳理了软件开发团队在选择云开发环境(CDE)平台时需要考量的因素。

译自 How to Choose a Cloud Development Environment 。

我还记得大约10年前，有家金融机构试图理顺他们的开发流程，并打造所谓的平台。他们发现新开发者的入职时间非常缓慢，技术栈应用也不一致。他们有架构委员会，但与日常开发脱节。敏捷方法让人们认为应该把所有过程自动化，于是他们的流程就朝这个方向发展。

他们正在朝着构建云开发环境(CDE)的方向迈进。他们模糊地意识到，如果能把“最佳实践”的工具集成在一起，可能会提供良好的入职体验。但一个问题是如何协调组织内不同开发团队的经验，以及如何避免丢失可能与某特定环境相关的专业知识。为了标准化是否应该牺牲专业性?

本文旨在帮助您评估这个问题对团队的影响，面对各种新兴的CDE选择。它仍然需要对您的团队在组织内的运作方式进行诚实反思。

CDE-WordPress类比

即使不谈开发，也能从云服务的角度思考这些问题。和许多其他在线出版物一样，The New Stack基于WordPress平台运行。当我写文章时，常需要插入包含尖括号的代码段。如果直接粘贴，尖括号可能被当成指令，或被替换成HTML实体，比如"<"和">"。在我作为平台用户时，这就碰到了系统问题。当下时间就开始流逝了。

• 平台或谷歌会指引我找到解决方案吗？
• 谁真正理解这个问题？
• 理解问题的人是否也能访问平台？
• 解决需要多长时间？
• 我是应该避免代码段呢？

结果优秀的内部团队迅速定位了问题，提供了适当的WordPress插件访问权限。时间很宝贵，但也不算特别紧迫。重点是作者要尽可能准确表达意图。不过如果迫不得已，我还可以稍后更正文章。

现在想象您的开发团队面临最后期限，遇到了棘手问题。团队有能力定位问题吗?自由发挥的怪咖开发者更重要，还是保持协作更重要?如实回答这些问题，有助于选择联网环境。

按需计算的CDE

现在，我们认为 CDE 是按需提供开发环境的服务，内置构建和部署应用所需的全部工具和预配置组件——只要存在您要构建应用对应的模板。CDE 的运行性能在可预测范围内；即您大致知道容器可以调用多少 RAM 和 CPU。像大多数云产品一样，CDE 可能只能通过网络访问。在我上一篇文章中，我分析了热门的在线环境 Replit 运行 Ghostwriter AI，注意到上手非常容易。

Gitpod 的 CDE 白皮书提出 CDE 应具备公平性、一致性、可扩展性和按需服务等四大质量。任何人都可以启动一个会话获得开发环境，获得与他人相同的环境。不仅是启动容器然后交付，需要提供完整流水线，从代码构建完整应用。就像 Google 文档一样，CDE 会话可以即时启动，全天候 7*24 小时服务。协作非常自然。

自托管与标准化

Daytona 提出了所谓标准化开发环境(SDE)的概念，这在很大程度上与自托管 CDE 和控制相关。Coder.com 对自托管也有稍不同方法。

许多大公司已经建立内部云环境，理由包括控制成本、安全和扩展性。SDE 认识到需要创建模板，允许开发者使用自己工具或访问打包人工智能的资源；本地或在线工作。

自托管为内部用户提供更大灵活性和掌控感，但明显更有利于有能力进行综合的组织。

部分开发者确实喜欢配置

有些工程师确实热衷于配置和基础设施编码工作。如果团队中有这方面技能，应充分发挥。相反，许多开发者不愿处理与日常代码不同的脚本。更重要的是，他们可能未深入研究过如 Ansible、Chef 等当年流行系统的工作方式，解决平台问题时可能编写意大利面式代码。

入职是否就为了标准化？

来自环境封装的最大收益(软件即服务，SaaS)——如 GitHub Codespaces ——就是极大地加快了入职速度。由于每个用户的环境略有不同，团队对该环境的知识不会存在广泛差异，这是由不同的安装方式造成的。对任何入门文档来说，每位用户获得的指引都更可能完全一致。但存在这样一种假设，即我需要环境与上一位用户出于同一原因，这是有问题的。

更为开放的入职方式允许每个人快速获取环境，不假设他们进入后要做什么。一个很好的例子是一个好奇的市场主管，不仅想做报表，还想运行当前版本。让他们启动版本构建是有意义的，但如果一开始就要设置 SSH 隧道，那就不太合适了。他们可以更新图片中的未来客户标志，仅通过网页浏览器做不到这一点，这样的小试牛刀可能带来巨大收益。另一方面，有人进来快速评估项目时，可能希望运行不同时间点的版本，如果不能完全控制熟悉的工具，他们就会受限。

创新编码 vs 产品编码

集装箱标准化规格的巨大优势在于统一了尺寸。这极大地改革了运输成本控制，因为可以提前根据标准建造集装箱端口。您可能会质疑为何上世纪70年代才推广开来。的确，在此之前有大量尝试——真正实现标准化的是国际贸易模式。同理，您必须如实看待团队，判断他们更注重交付还是自由探索。

数据安全性从未像想象中那么重要。更多是法律地域问题——数据可以保存于何处。否则，内部数据中心的数据不太可能比存储于专注数据安全的公司的数据中心更安全。但“安全”也可能意味着自己的沙盒安全，或限制开发人员笔记本中的代码量。在大多数情况下，这仍然更是一个政治而非字面问题。

从团队实际工作入手

所以，重点是确定团队的真实工作方式，然后推进面向未来的功能。AI 现在可能是福音，但未来可能是必须。您现在可能很清楚需要什么规格的容器，但这可能会改变。您的结论可能是一个共享的 git 仓库就够了。可能是几个 Docker 容器。可能是一个完整的 CDE，或一些自建服务。但无论哪种方式，都要从解决潜在第一个冲突入手。