使用率激增250%，这份报告再次将 Serverless 推向幕前

Posted 2021-06-16 风风风啊

向幕前

 

作者 | 望宸

 

本文是对 Datadog 最新的一份 Serverless 报告的解读，欢迎大家留言讨论。

 

每项新技术的产生和演进过程中，都会有他自己的拥趸，也会有持怀疑论者。Serverless 的美在于他可以尽可能的解放客户在基础设施上的投入，只需专注于自己的业务，让技术产生更多商业价值，同时，客户只需要真正为使用量付费，无须让计算资源常驻。

 

“Datadog 上一半的 AWS 客户使用了 Lambda，80% 的 AWS 容器客户使用了 Lambda。”

 

是的，这个数据来自 Datadog 去年的一份调研报告，客观反映了 Serverless 在海外市场的落地进程。一年之后，Datadog 发布了第二份 Serverless 调研报告，我们来一起看看 Serverless 在海外的最新进展，这对于无论是已经投入建设 Serverless，还是仍处于观望状态的决策者和使用者而言，也许都能获得一些参考。

 

观点一：Lambda 的调用频率比两年前高 3.5 倍，运行时长达 900 小时 / 天

Serverless 的使用深度如何来定义？

自 2019 年以来，一直在使用 Lambda 的企业已大大提高了其使用率。平均而言，到 2021 年初，这些公司每天调用函数的次数是两年前的 3.5 倍。此外，在同一组 Lambda 用户中，每家企业的功能平均每天平均运行达 900 个小时。

普通云服务器，是按服务器的租用配置和租用时长进行收费的，其中，租用配置是依据 vCPU 和内存定价。

而函数计算则不同，按使用过程中的调用次数和函数运行时长收费的。因此，调用次数和函数运行时长是衡量客户使用 Serverless 深度的指标。报告中未提供每天调用次数绝对值的信息，但我们可以依据每天运行 900 小时运行时长的数据，对客户在 Serverless 的消费做一个区间预估。

以阿里云函数计算的收费标准来计算，使用预付费模式：

每 1 GB 计算力的实例运行 1 秒所需的费用是 0.00003167 元，以内存规格 1GB，每天运行 900 小时来计算，预计将消费 102.6 元，年度消费是 3.7 万，再搭上存储、网络、安全、数据库等其他云产品的消费，已经是一个中型企业的云上支出了。此外，函数的调用次数所产生的费用通常不会太多，尤其是 Python 这类和 AI 建模相关的函数应用，阿里云函数计算每天调用 100 万次的费用是 13.3 元。

观点二：Lambda 执行时长的中位数是 60 毫秒，仅为一年前的一半

事件驱动架构下，执行时长是一个关键生产因素

函数的执行时长是 FaaS 领域的新概念，因为 FaaS 是事件驱动架构，实际触发时，才会调用计算资源执行函数应用并进行计费，函数应用执行时间越长，费用就会越高。不同于函数计算，普通云服务器则是按租用服务器来计费，虽然普通云服务器也提供自动弹性伸缩的功能，但由于本身不是事件驱动架构，导致伸缩规则上是受限的，而且，普通云服务器是按秒计费，而业内的 FaaS 产品，例如 Lambda、阿里云函数计算都已经支持按毫秒计费，计费颗粒度越细，计算成本的优化空间就越大。

从数据结构上我们可以看到，越来越多的 AWS 客户正在遵循官方提供的成本优化最佳实践，来缩短函数的执行时长，从而进一步优化计算成本，最大程度发挥 Serverless 的成本优势。

下图中，函数执行时长曲线的尾巴很长，这表明 Lambda 不仅支持短期作业，而且已经在支持计算密集型的用例。虽然此份报告没有展示哪些计算密集型的业务场景使用了 Lambda，但从国内云厂商宣传的案例看，主要是音视频处理、AI 建模类的应用。

观点三：除 AWS Lambda 外，Azure Function 和 Google Cloud Function 的增长也很迅速

百家齐放是行业走向成熟的必经阶段

AWS Lambda 是最早的 FaaS 产品，Azure 和 Google 紧随其后，推出了 FaaS 产品，他们的增速可能得益于整个行业的成熟度，从一年前只有 20% 的 Azure 客户使用 Azure Function，一年后，这一数据已经增长到了 36%，而 Google 已经有 25% 的云上客户在使用 Cloud Function 了。

该部分，报告中引用了 Vercel 这个案例：

Vercel 是一个很实用的网站管理和托管工具，可以快速部署网站、App，甚至不需要购买服务器、域名、安装与配置 nginx、上传网站文件、添加 DNS 解析项、配置网页证书，最重要的是个人使用是永久免费。

Vercel 托管的都是一些耦合度不高的应用。很显然， Vercel 的这一商业模式充分利用了 Serverless 技术的成本优势，来尽可能降低免费个人用户带来的服务器成本，通过函数应用来处理来自服务端渲染、API 路由等的请求。在过去的一年里，Vercel 每月的服务器调用次数从 2.62 亿次增加到每月 74 亿次，增长了 28 倍。

Vercel 官网：https://vercel.com/

 

观点四：AWS Step Functions 是 Lambda 的最佳伴侣，平均每个工作流包含 4 个函数，并逐月上升

函数应用的编排功能正在拓展函数应用的边界

一个完整的业务逻辑通常不是一个函数应用就能完成的，需要用到多个函数应用，甚至还涉及到弹性计算、批量计算等计算单元。这时候，通过工作流的编排能力，对各个计算任务进行顺序、分支、并行等方式的分布式编排，可以简化繁琐的业务拼接带来的代码工作，还能可视化监控整个业务流程中各个执行环节的状态，一举两得。AWS Step Functions 就提供了这样的功能。

报告显示，平均每个 Step Functions 工作流包含 4 个 Lambda 函数，并且呈现逐月增长的趋势。说明越来越的客户正使用工作流来处理越来越复杂的业务逻辑。其中，执行时间在 1 分钟内的工作流占比 40%，但也不乏一些执行时长多于 1 小时甚至超过 1 天的工作流，这些长时间执行的工作流以 AI 建模为主。

 

该部分，报告中引用了 Stedi 这一案例，这家企业是在 B2B 交易的交易领域提供结构化消息发送的服务，例如营销邮件的推送等服务，这类业务场景具备事件触发、短时间需要调用海量目标邮箱邮箱的特点，Serverless + 工作流就可以很好的满足了客户在成本和开发运维效率上进行优化的诉求。

Stedi 官网：https://www.stedi.com/

 

观点五：四分之一的 AWS CluodFront 客户使用 Lambda @Edge

边缘正成为 Serverless 的新市场

Lambda@Edge 是 Amazon CloudFront 的一个功能，它可让客户在靠近应用程序用户的地方运行代码，从而提高性能，降低延迟。使用 Lambda@Edge，客户无需在全球多个地方预置或管理基础设施，只需按使用的计算时间付费，代码未运行时不产生费用。

 

相当于在边缘的场景下，网络将 Serverless 的计算能力一起提供给客户，而无须从云端调用算力，提高了那些对延迟敏感的边缘业务的客户体验，例如物联网场景下视频监控和智能分析、业务监测和分析等任务。

 

报告显示，四分之一的 Amazon CloudFront 客户使用了 Lambda@Edge，其中 67% 的客户的函数执行时长不到 20 毫秒，说明这部分应用对延迟非常敏感，这类的边缘业务需求越多，Serverless 在边缘端的潜力就越大。

观点六：超过一半的客户函数预留实例的资源使用率不到 80%

冷启动是事件驱动架构下一个无法回避的命题

 

尤其是在 Java/.Net 的编程框架下，应用的启动会更慢，因为 Java 需要初始化其虚拟机 (JVM) ，并将大量类加载到内存中，然后才能执行用户代码。业内提供了很多优化冷启动的思路，例如提供函数预留实例，或者通过按需加载和更高效的存储和算法来提升容器镜像的拉取速度，从而优化冷启动速度。

 

本质上讲，函数预留实例是避免冷启动的一个见效很快的方式，但他并没有从根本上解决冷启动的问题，资源预留的越多，浪费的就越多，这和 Serverless 主张的按需使用是背道而驰的。因此，今年的报告非常关注客户在函数预留实例的使用率情况。

 

报告显示，57% 使用函数预留实例的客户用了不到预留实例中 80% 的资源，其中，超过 30% 的客户仅用了不到 40% 的资源；使用率达 80%-100% 的客户超过 40%，那么这部分客户应当仍然会遇到冷启动的问题。因此，不断优化业务的预留实例设计仍是厂商和客户需要共同面对的命题，相关的最佳实践会有较高的指导意义。感兴趣的朋友可以看看阿里云函数计算的这份最佳实践。

 

观点七：开源无服务器框架是部署函数应用的主要方式

应用拆的越细，部署难度越大

 

Serverless 架构下，手动部署几个函数应用可能不太复杂，一旦当应用扩展到几十、几百个的时候，应用的部署难度就会被成倍放大，此时通过一些部署工具来部署，可以提高部署效率。正如 Kubernetes 是用来自动部署、扩展和管理容器化应用程序的，在管理容器的过程，Kubernetes 已经是必不可少的工具。

 

报告显示，80% 以上的客户使用 Serverless Framework 来部署和管理函数应用，虽然报告未给出原因，但大体离不开 Serverless Framework 的易用性、开放性和社区属性，报告预计基础设施即代码类的部署工具在大规模部署无服务器应用程序方面将扮演更重要的角色，AWS 自研的三个部署工具，vanilla CloudFormation、AWS CDK 和 AWS SAM 的使用率分别是 19%、18% 和 13%。（存在同一个客户同时使用两个或多个工具，因此使用率叠加后高于 100%）

回到国内，阿里云、百度云、华为云、腾讯云均提供了自家闭源的部署工具，腾讯云和 Serverless Framework 合作，开发了 Serverless 应用中心，阿里云则是在去年开源了 Serverless Devs，提供函数应用的部署、运维和监控，此外，国内另一款提供 Node.js 开发态框架的开源项目 Midway，已经获得 4k+ 的 star，相信随着参与 Serverless 的开发者的增加，国内开源工具生态会越发活跃。

 

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

 

Serverless 天然支持多语言的开发框架。那么问题也来了，哪类编程语言最为流行呢？

 

报告显示，58% 的用户使用 Python，Node.js 则占据了 31% 的份额，Java、Go、.NET Core 和 Ruby 的份额均未超过 10%。但考虑到不同厂商各自的特点，阿里云上的 Java 份额可能会更高些，Azure 上 .NET 的客户会更多些。

有趣的是，在小型的 Lambda 运行环境中，Node.js 的份额高于 Python，随着函数规模的增长，Python 就越来越流行，而在企业级组织中，Python 的使用频率是 Node.js 的 4 倍，如下图：

雷卷在阿里云内网分享了报告中编程语言部分的分析：大型企业在大数据、AI 等方面，使用 Python 比较多，而且他们使用的 Lambda 量也比较大，所以在 Lambda 的数量上 Python 有绝对的优势；Node.js 应用用不了那么大的运行期 (多核 CPU 和大内存），通常都是小型实例，另外可能是个人的 Node.js 开发者，通常也会选择小型的 Lambda 环境。

 

此外，各类编程语言的版本的使用分布如下，依次递减，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。

 

总结  

整体上，相比去年，国外 Serverless 的使用群体在迅速扩大，函数执行时长不断增加，使用方式也越加成熟，开发者工具也更佳开放。在国内，Serverless 已经不在局限一些离线任务或低耦合性应用，已经有不少企业客户将 Serverless 应用于生产环节的核心链路上，例如世纪联华将交易系统、会员系统、库存系统、后台系统和促销模块等核心应用均部署在函数计算上，来减轻客户在基础设施上的投入；闲鱼已经开始实践对传统巨型应用的 Serverless 化改造，去攻克在 Functions 之间代码复用、对函数的依赖做统一升级等业内难题。应用的改造需要时间和窗口期，相信会有越来越的企业客户选择 Serverless 来解放双手。

英文报告链接：https://www.datadoghq.com/state-of-serverless/

关键词：站长资讯中心，站长资讯，站长新闻