亚马逊AWS官方博客

构建 AWS 无服务器开源社区

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

关于 Amazon 开源

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

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

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 发布让社区了解情况,让客户能够开始使用它。

持续改进

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

业务指标 社区指标 运营指标
下载量/周 问题数量、PR 数量 安装速度
按 Python 版本划分的下载量 首次获得响应所需时间 首次操作成功率
按 SAM CLI 版本划分的下载量 关闭 PR 所需时间 命令延迟
社区 PR 数与内部 PR 数 错误率
问题提出至今的时长

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

令人难以置信的社区

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

在 OSCON 2019 上与我联系

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