构建 AWS 无服务器开源社区

在本文中，我将向您介绍我自 2016 年以来一直积极参与的活跃的无服务器开发人员开源社区。在我着手在 AWS 上开放两款战略产品的源代码之前，我并不了解开源社区的规模和潜力。

关于 Amazon 开源

Amazon 相信并支持开源软件。十多年来，我们为数百个项目做出了贡献，并不断拓宽合作范畴、增加代码贡献，帮助维持健康的开源社区。我们在 Github 上有数百个代码库，其中的开源的内容既包括 SDK、客户端工具、开源 JDK、Open Distro for Elasticsearch，还包括我们的某些服务的核心组件，例如 s2n 和 Firecracker。

无服务器技术为工具构建者创造机会

2014 年，我们推出了 AWS Lambda，这是我们的首款无服务器计算服务，允许您在不必考虑服务器的前提下运行代码。在 Lambda 上构建应用程序时，您不必管理服务器，只需为实际使用的资源付费，您的应用程序会根据使用情况自动扩展，并且具有高可用性和容错性。您的无服务器应用程序通常使用其他 AWS 无服务器服务来提供 API 终端节点、数据库、持久存储等。

AWS 服务会为您处理大量繁重工作。使用基础设施即代码模式，您可以编写配置文件来为 API 终端节点、用户身份验证、工作流等预配置服务。预配置完成后，AWS 会负责为您运行服务。这意味着您可以主要关注业务逻辑，然后偶尔编写一些底层命令即可。这也意味着所有代码优先的开发人员工具（如 IDE、测试工具、构建系统、部署引擎等）都需要支持配置创作和管理。

开源无服务器开发人员工具

目前已有大量开发人员工具，帮助开发人员习惯无服务器带来的大幅简化。猜猜怎么样？ 其中大部分工具都是开源的！ 让我们来看几个例子：

• Serverless Framework：根据开源社区统计数据来看，这是迄今为止规模最大、最受欢迎的工具：在 Github 上获得了 3 万颗星、在 NPM 上有庞大的下载量，贡献者人数超过 500 人，并且有由社区构建的丰富插件集。

• 有几种特定于编程语言的库可用于创建无服务器应用程序：适用于 Node.js 的 Claudia.JS、适用于 Python 的 Zappa、适用于 Golang 的 Sparta、适用于 PHP 的 Bref 等。

• Apex 提供了一种简单且规范化的工具来管理您的 Lambda 函数。它可以与 Terraform 等基础设施预配置工具结合使用，以管理整个应用。

来自 AWS 的开源无服务器工具

除社区外，AWS 还为无服务器开发人员构建并开源了多种工具：

• AWS SAM 是一种与语言无关的框架，用于创建、测试、部署和管理无服务器应用程序。我是参与构建 SAM 的工程师之一，所以我将在下面更详细地介绍 SAM 的发展历程。

• Chalice：一种 Python 微服务框架，用于在 Lambda 上运行类似 Flask 的应用程序。

• AWS Amplify：使用无服务器后端构建 Web 和移动应用程序。

• Serverless Express：在 Lambda 上运行基于 Express.js 的应用程序。

• Serverless Java Container：在 Lambda 上运行 Java Springs、Jersey 和 Spark 应用程序。

• 这其中的每个项目都有自己的活跃社区，有数百名开发人员与 AWS 联手合作。

这一切是如何发生的？ 下面着重介绍了我如何围绕 SAM 创建社区。

SAM 开源之旅

2016 年 10 月：开放规范

AWS SAM 的开源历程始于 GitHub 上的一种规范。该规范规定了将无服务器应用程序定义为 YAML 配置文件的语法。客户可以编写配置文件（称为 SAM 模板），并使用 aws cloudformation deploy CLI 命令将应用程序部署到 AWS 云。我们开放了规范，邀请社区与我们联手构建用于定义无服务器应用程序的模型。

社区立即开始从各个角度积极做出贡献，从功能创意和文档改进，一直到错误报告。在几个月内，有人提交了一个 GitHub 问题，要求我们将实现的源代码公开。

2018 年 4 月：开源实现

快进到 2018 年：我们最终开放了 SAM 的源代码。对我个人而言，这是一个值得骄傲的时刻，因为这是我第一次开放关键业务组件的源代码。

在做出这个决定之前，我们必须回答一个关键问题：SAM 是一种部署到超过 15 个 AWS 区域并与其他服务深度集成的全球服务。开源是否确有可能？

• 如果有人窃用了我们的秘诀该怎么办？

• 如果有人添加了恶意代码该怎么办？

• 如果有人贡献了质量低下的代码该怎么办？

• 我们能否将开源产品作为服务运行？

• 我们能否保密一些功能？

• 我们是否有合适的团队来管理开放源代码？

• 我们写了一份内部文档（Amazon 著名的“PRFAQ”之一）来回答这些问题。目标就是让利益相关者相信，这确实是一个好主意。但该文档最终的主题是“如何运作开源项目并建立一个成功的社区”。 我们知道，如果我们能建立一个充满活力的社区，就可以将开源开发的灵活性与 AWS 的质量保证实践相结合，从而快速生成高质量的软件。

首先建立社区，然后构建软件

开放沟通

为了建立一个健康的社区，我们需要在每个人之间保持开放沟通，包括 AWS 工程师在内。我们希望每个人都感到自己是同一个团队的成员。所以我们创建了一个 Slack 频道 (#samdev)，其成员人数现已超过 1,000 人，包括贡献者、客户、工程师等。

开放开发

在这个团队中，我们希望所有软件开发人员（同样包括来自 AWS 的开发人员）使用相同的工具、实践和流程。我们制作了详细的开发指南，公开讨论了设计，通过拉取请求公开审查和评判了彼此的代码更改，并就发布时间进行了沟通。

在软件开发的方方面面均得到开放时，就能建立信任、提高代码质量，让社区感到更加安心。

开放优先级

与工程有关的一切都是开放的。但产品优先级和决策仍然是秘密进行的。因此，我们启动了征求评论流程（示例 RFC），让社区可以提供反馈并就问题投票表决。我们使用标签来设置问题和 PR 的社区优先级，以确保社区就后续要开展的工作达成共识。这也让客户和贡献者能够清晰了解我们如何看待某个问题/任务。

部署自动化

对于 AWS 上的开源项目，这是我最喜欢的部分。社区贡献代码和思想领导能力，我们则代表社区处理部署和发布事宜。AWS 对大规模部署和管理 Web 服务有深入的了解。在内部，我们将 SAM 部署到所有 AWS 区域。我们通过应用自动回滚、警报、金丝雀部署等最佳实践来确保安全部署。我们对每项代码更改执行安全性审查，确保向后兼容性，并处理部署失败和中断。

部署工作完成后，我们通过 GitHub 发布让社区了解情况，让客户能够开始使用它。

持续改进

每周，我们都会召开内部会议来跟踪社区、软件和服务的运行状况。我们会审核一组指标、讨论重要问题，并确定改善社区和软件运行状况的方法。以下是我们审核的一些指标：

更广泛的 AWS 无服务器组织可以查看每周运营审核的信息。我们经常与其他流行的开源项目（如 AWS CLI 和 SDK）交流心得，以确保我们不会重复犯下彼此的错误，并且持续提高质量标准。

令人难以置信的社区

对于我们围绕 AWS SAM 产品建设起的社区，我倍感自豪。100 多名开发人员贡献了颇有价值的功能特性，在我们发展壮大的过程中坚持不懈地为此产品提供支持。加入 #samdev Slack 频道，并查阅 SAM 贡献指南，切身参与这个茁壮发展的社区！

在 OSCON 2019 上与我联系

我将在 OSCON 2019 大会上发表关于建设开源社区的演讲。如果您碰巧离会议举办地不远，不妨来和我打个招呼。

本文转载自 AWS 技术博客。

原文链接：

https://amazonaws-china.com/cn/blogs/china/building-open-source-communities-aws-serverless/