使用率激增250%，这份报告再次将 Serverless 推向幕前
简介：相比去年，国外 Serverless 的使用群体在迅速扩大，函数执行时长不断增长，使用方式也越加成熟，开发者工具也更佳开放。
向幕前
做者 | 望宸html
本文是对 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 架构下，手动部署几个函数应用可能不太复杂，一旦当应用扩展到几10、几百个的时候，应用的部署难度就会被成倍放大，此时经过一些部署工具来部署，能够提升部署效率。正如 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 十二、Node.js 十、Python 2.七、Java 八、Go 1.x、.NET Core 2.一、.NET Core 3.1。
总结
总体上，相比去年，国外 Serverless 的使用群体在迅速扩大，函数执行时长不断增长，使用方式也越加成熟，开发者工具也更佳开放。在国内，Serverless 已经不在局限一些离线任务或低耦合性应用，已经有很多企业客户将 Serverless 应用于生产环节的核心链路上，例如世纪联华将交易系统、会员系统、库存系统、后台系统和促销模块等核心应用均部署在函数计算上，来减轻客户在基础设施上的投入；闲鱼已经开始实践对传统巨型应用的 Serverless 化改造，去攻克在 Functions 之间代码复用、对函数的依赖作统一升级等业内难题。应用的改造须要时间和窗口期，相信会有愈来愈的企业客户选择 Serverless 来解放双手。
英文报告连接：https://www.datadoghq.com/state-of-serverless/
本文内容由阿里云实名注册用户自发贡献，版权归原做者全部，阿里云开发者社区不拥有其著做权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。若是您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将马上删除涉嫌侵权内容。