Serverless 2021 最新调查报告

云原生Serverless

于 2021-08-28 23:33:00 发布

阅读量358

点赞数

分类专栏： serverless 云原生文章标签： serverless 云原生无服务器架构

原文链接：https://www.datadoghq.com/state-of-serverless/

版权

云原生同时被 2 个专栏收录

14 篇文章 4 订阅

订阅专栏

serverless

7 篇文章 1 订阅

订阅专栏

数据更新于 2021年 5月，数据来源于国外 DATADOG 的调查报告

近两年以来 Serverless 已经获得了极大的关注，从云原生初创公司到大型公司。借助于 Serverless，开发团队可以更专注得将想法推向市场化，只需为他们的使用量付费即可，不必关心相关基础设施。

在这份调查报告中，我们调查了数千家公司运行的数百万个函数，以了解 Serverless 在生产环境中的实际使用情况。

其中 Serverless 应用场景广泛，从短任务到面向用户的应用程序。AWS Lambda 是最成熟，使用最广泛的 Faas 产品，同时也可以看到 Azure Functions 和 Google Cloud Functions 的使用率也增长惊人。当前 Serverless 的生态系统已经不局限于 Faas，还包括其他数十种服务，可以帮助开发者更快得构建应用。四分之一的 Amazon CloudFront( CDN 产品)用户已经接受了 Serverless 边缘计算，同时也有不少组织开始利用 AWS Step Functions 用来管理各种分布式应用。

Lambda 函数的调用频率是两年前的 3.5 倍

AWS Lambda 通过构建高度可扩展的应用程序使开发人员可以更快地进行创新，无需担心基础设施。如今，团队不仅在试验 Serverless 产品，而且将其作为其软件系统的关键部分。事实上，我们的研究表明，自 2019 年以来一直在使用 Lambda 的公司已经显著增加了 Lambda 的使用率。平均而言，在 2021年初，函数每天被调用的频率是两年前的 3.5 倍。此外，在同一组 Lambda 用户中，每个组织的 Lambda 函数平均每天运行 900 小时。

`Azure Functions` 和 `Google Cloud Functions` 势头强劲

AWS Lambda 率先发起了 Serverless 热潮，但并不是唯一的游戏参与者。Azure Functions 和 Google Cloud Functions 在各自的云平台中的使用率都在增长。在过去的一年中，运行 Azure Functions 的 Azure 的组织的份额从 20% 攀升至 36%。在 Google Cloud 上，近四分之一的组织现在使用 Cloud Functions。尽管 Cloud Functions 是推出的三个 FaaS 产品中的最后一个，但 Serverless 在 Google Cloud 中并不是一个新概念——云平台早在 2008 年就推出了 Google App Engine，这是它的第一个完全无服务器的计算服务。但今天，我们看到了势头的转变转向谷歌较新的无服务器产品，即 Cloud Functions 和 Cloud Run。

现在的 Lambda 调用的持续时间比去年短很多

Lambda 越来越多地用于为需要低延迟的、面向客户的应用程序提供支持。2020 年，Lambda 调用时长的中位数仅用了 60 毫秒——大约是前一年的一半。一种可能的解释是，越来越多的组织正在遵循 Lambda 最佳实践优化代码，代码逻辑高度专注于特定的工作负载，这有助于缩短调用的持续时间。我们还注意到延迟分布的尾部很长，这表明 Lambda 不仅支持短期工作，而且还支持计算密集型用例。

Step Functions 提供从 Web 应用程序到数据通道的连接

使用 AWS Step Functions ，开发人员能够构建涉及多个 Lambda 函数和 AWS 服务的事件驱动工作流。在这些工作流中，Step Functions 涵盖错误处理、重试、超时和其他应用程序逻辑，这有助于在 Serverless 应用程序扩展时降低操作复杂性。我们的研究表明，平均 Step Functions 工作流包含 4 个 Lambda 函数，而且这个数字正逐年增长。

Step Functions 提供两种类型的工作流：标准的 (Standard) 和快速的 (Express)。我们注意到超过 40% 的工作流在一分钟内执行，这表明组织很可能使用快速 (Express) 工作流来支持大容量事件处理工作负载。但是，尽管许多工作流执行得很快，但还是有些工作流会运行一天多。事实上，最长的 Step Function 工作流运行时间超过一周。例如，Step Functions 工作流可以包括在 Amazon ECS 或 EC2 实例上运行的活动工作线程，这意味着它们的执行时间可以长于 Lambda 函数，毕竟 Lambda 函数的超时时间为 15 分钟。这使 Step Functions 能够支持大量用例，从延迟敏感应用（如 Web 请求处理）到复杂、长时间运行的任务（如大数据处理作业）。

四分之一的 CloudFront (AWS CDN) 用户已接受 Serverless 边缘计算

边缘计算由于能快速地就近处理数据引起了广泛的关注。如今，四分之一的使用 Amazon CloudFront 的组织正在利用 Lambda@Edge 为其全球用户提供更加个性化的体验。例如，Lambda@Edge 可以根据用户特征（例如设备类型）动态转换图像，或为不同版本的 Web 应用程序提供 A/B 测试。

通过利用 CloudFront 的边缘站点网络，Lambda@Edge 能够在更接近用户的地方执行计算，而无需重新修改源站服务器的配置。我们的数据显示，67% 的 Lambda@Edge 函数在 20 毫秒内运行，这表明无服务器边缘计算具有巨大的潜力，可以以最小的开销应对延迟敏感的应用程序。随着这项技术的成熟，相信越来越多的人会利用边缘 Serverless 改善他们的应用体验。

使用 Serverless 的组织在预留函数并发量上花费超支

当 Lambda 函数在一段时间不活动后被调用时，它会经历短暂的执行延迟，称为冷启动。对于需要毫秒级响应时间的应用程序，冷启动可能无法启动。2019 年底，AWS 引入了预置并发量，通过保持执行环境初始化并准备好响应请求来帮助 Lambda 用户降低冷启动时间。

根据我们的数据，为 Lambda 函数配置合适的预置并发量，仍然是用户面临的挑战。超过一半的函数使用不到 80% 的预置并发量。同时，超过 40% 的函数使用了它们的全部预置并发量，这意味着它们可能仍然会遇到冷启动，需要更多的预置并发量。Application Auto Scaling 提供了一种解决这些问题的方法，允许用户根据利用率自动扩展预置并发量。

我们还看到，配置预置并发量的场景主要是 Java 和 .NET Core 函数，由于这些运行时的固有特性，这些函数的启动时间通常比 Python 或 Node.js 慢。例如，Java 需要初始化其虚拟机 (JVM) 并将大量类加载到内存中，然后才能执行用户代码。

Serverless Framework 是使用 AWS CloudFormation（AWS 应用编排服务）部署 Lambda 应用程序的主要方式

随着 Serverless 应用数量的递增，手动部署 Lambda 函数和其他资源将会变得越来越麻烦。AWS CloudFormation 允许开发人员在集合（称为堆栈）中预置 AWS 基础设施和第三方资源。并且它也是 AWS 云开发工具包 (CDK)、AWS Serverless 应用程序模型 (SAM) 和Serverless Framework等框架的底层部署机制。

在这些工具中，开源的 Serverless Framework [https://github.com/serverless/serverless]是迄今为止最受欢迎的——如今，超过 90% 的组织都在使用它，这些组织使用 AWS CloudFormation 管理其 Serverless 资源。除了 Serverless Framework，19% 的组织使用 vanilla CloudFormation，18% 使用 AWS CDK，13% 使用 AWS SAM。请注意，由于每个组织可能使用多个部署工具，因此这些值加起来超过 100%。

在 Serverless 应用程序中使用的 CloudFormation 堆栈中，65% 仅包含一个 Lambda 函数。此外，超过一半的函数（57%）未使用 CloudFormation 部署。这表明，许多组织仍处于使用自动化部署和 Serverless 工作流的早期阶段。但是，正如 Kubernetes 和 Amazon Elastic Container Service (ECS) 等容器编排平台对于管理大量容器变得越来越重要一样，预计基础设施即代码工具（应用编排类服务）在大规模部署 Serverless 应用程序方面将扮演更重要的角色。

Python 是最流行的 Lambda 运行时，尤其是在大型环境中

自 2018 年以来，Lambda 已提供了对六种运行时的支持：Node.js、Python、Java、Go、.NET Core 和 Ruby。然而，Python 和 Node.js 仍然在 Lambda 用户中占据主导地位，占函数总数的 90%。所有部署的 Lambda 中有 58% 运行 Python（比一年前上升 11 个百分点），另有 31% 运行 Node.js（与去年相比下降 8 个百分点）。

当我们检查按环境大小划分的运行时使用情况时，出现了一个有趣的趋势：虽然 Node.js在小型 AWS 环境中超越 Python，但随着环境规模的增长，Python 变得越来越流行。在使用 AWS 服务最多的组织中，Python 的使用频率是 Node.js 的四倍。

截至 2021 年 3 月，最受欢迎的 runtime 依次是：

Python 3.x
Node.js 12
Node.js 10
Python 2.7
Java 8
Go 1.x
.NET Core 2.1
.NET Core 3.1

在用 Python 编写的函数中，超过 90% 使用 Python 3，其中 Python 3.8 是最受欢迎的版本。随着用户越来越多地迁移到 Python 3，Python 2.7 比一年前下降了 25 个百分点。AWS 已宣布计划在 2021 年 5 月放弃对 Node.js 10 的支持，因此我们预计 Node.js 12 和新增的 Node.js 14 的使用量也会增加。尽管 Java 11 自 2019 年末就已经开始支持了，但是 Java 8 在 Lambda 用户中的受欢迎程度是 Java 11 的五倍之多。