2019 年 Serverless 应用报告：三分之二的落地实践都成功了？

Gartner 报告表明：到 2020 年，全球将有 20% 的企业部署 Serverless 架构。同时，很多大型厂商，例如亚马逊、微软和谷歌等都看好 Serverless 领域，并投入了大量的资金。那么，2019 年 Serverless 的应用情况到底如何呢？

近日，O’Reilly 针对 Serverless 的应用情况进行了首次调查。本次调查共采访了来自不同国家、地区的 1500 多名开发者，这其中有使用 Serverless 不到一年的新手开发者，也有三年以上的资深开发者，所以调查得出的结论可以在一定程度上呈现 Serverless 目前的应用情况。

哪些行业、哪些岗位的人在应用 Serverless？

从上图来看，探索和使用 Serverless 的人并不局限于某个单一的岗位或角色。这表明软件团队在逐渐转向承担更多的基础架构的责任，并且选择使用 Serverless 来支持。

本次调查超过五分之一的受访者是来自软件行业的，其次来自金融和银行业的。软件行业的开发者关注和应用 Serverless 似乎是理所当然的事情，而金融和银行行业关注 Serverless，主要是因为其垂直领域出现了越来越多的金融科技初创企业，它们承担了传统基础架构的责任，并且以更开放的心态，接纳和拥抱 Serverless。

应用 Serverless 的企业规模如何呢？根据调查结果显示，只有三分之一的受访者在规模小于 100 人的公司工作，其中企业规模大于 10000 人的受访者占据了差不多五分之一的份额。这也在一定程度上表明，目前关注 Serverless 的不仅是没有技术债务或管理费用的初创公司，大型企业也很重视 Severless。

企业如何应用 Serverless？

目前 Serverless 的实际使用情况如何呢？本来以为 Serverless 作为一项比较新的技术，落地情况可能不太乐观，但有趣的是，40%的受访者表示他们已经采用了 Serverless，这个结果完全出乎意料。

如果在细分的话，超过 50%的受访者已经采用 Serverless 1-3 年的时间，还有 15%的受访者采用 Serverless 超过了 3 年的时间。要知道，截止到今年 11 月，Amazon 推出的 AWS Lambda 功能只有 5 年的历史，应用经验超过 3 年的 Serverless 开发者实际上就是非常早的采用者了。

另外，我们发现在过去一年中采用 Serverless 的受访者有 30%，这说明有相当一部分的开发者（20%的受访者采用 Serverless 的时间在 2-3 年）在比较早的时期就已经在尝试和采用 Serverless 了。有人认为：“Serverless 的兴起与 Next Architecture 的趋势是相吻合的。”所以，在未来的 12-18 个月内，Next Architecture 的几大重要组成部分，如分布式、容器、云、Serverless 等都将实现可观的增长。

目前 Serverless 的落地情况如何？超过三分之二的受访者表示他们的组织大部分的 Serverless 落地都是成功的，他们表示：“Serverless 已经超越‘炒热度’的阶段，已经成为了一种实际可行的基础架构选择。”

Serverless 的落地成功率如何？根据调查结果显示，如果是拥有 Serverless 三年以上经验的开发者，大约有 79%是成功的，如果是一年到三年工作经验的开发者，大约有 75%是成功的，而如果是经验不足一年的新手开发者，只有 50%左右是成功的。这也在一定程度上说明应用 Serverless 所遇到的工具、数据和操作难题需要经验来解决。

为什么要采用 Serverless 呢？首先，“减少运营成本”是大家采用 Serverless 的第一大原因，应用 Serverless 之后，就无需为潜在的流量高峰购买大部分时间处于空闲状态的服务器机架；第二，“自动按需扩展”，采用 Serverless 之后，可以随时扩展到当前的使用量，消除了意外或者季节性流量高峰的困扰；第三是“无服务器维护”，由于企业中大部分开发人员都是软件工程师，并不是系统管理员，所以对于软件的修复、保护和管理并不擅长，而使用 Serverless 之后，这些工作都可以交给供应商，他们只需专注于软件开发。

现在应用 Serverless 存在哪些挑战呢？

首先，教育和培训现有员工。由于 Serverless 还是一个比较新的技术，很难找到标准、正式的培训，所以企业必须形成特定的文档培训员工，同时需要根据实践案例不断更新文档。另外，由于 Serverless 还处于高速发展阶段，各大供应商也在不断推出新功能，这也给企业培训员工增加了不少难度。

第二，“供应商锁定”。这是一个大家都会担心的问题，某个供应商平台编写的代码是不是能够迁移到其它平台。由于 Serverless 还是一个新兴市场，所以关于供应商之间的可移植性问题还处于观察阶段。

第三，集成/测试困难。对于 Serverless 架构而言，测试是复杂且劳动密集型的工作，需要处理更多的场景，同时因为需要依赖项的不同，集成也是一个需要解决的问题。

Serverless 的工具选型

在 Serverless 领域有哪些比较好的平台和工具可选呢？根据 O’Reilly 的云原生调查报告显示，Amazon 推出的 Serverless 产品因为先发优势，占据了市场的主导地位，而微软和谷歌也相继推出了自己的 Serverless 产品，并且借势各自的云平台获得了一定的市场份额。

在使用工具的调查中，“自定义工具”占据了首位。这说明目前缺乏一个标准化的工具来解决和管理部署到 Serverless 架构所遇到的问题，因此，客户要么是使用内部工具迁移，要么是花费时间精力来构建定制化产品。

为什么有些企业不用 Serverless？

前面讲了很多应用 Serverless 的原因和方法，接下来，我们分析一下为什么还有企业没有采用 Serverless？

60%的受访者表示是安全问题。因为很多行业对于 IT 环境的安全性要求很高，而采用任何新技术都可能会带来安全风险。另外，Serverless 为数据管理引入了另一种范式，使得敏感数据更加动态，企业无法更好的管理和控制这些数据，存在以下潜在的问题，例如访问权限、访问安全性、元数据或软件是否已打补丁等等。

另外，还需要面临 GDPR 等安全法规的挑战，在第三方服务器的云中，是否能够拥有与自己基础架构中相同级别的安全性呢？

不过，令人欣慰的是，虽然 Serverless 是个新技术，但是技术人员对此很感兴趣，大约一半的受访者都希望自家企业能够在未来三年内，尝试和落地 Serverless。

Serverless 的未来发展

岁末年初，对于技术的未来展望似乎是个惯例。因此，我们也采访了阿里云原生应用平台高级技术专家许晓斌，他和我们分享了对于 Serverless 2020 年发展的预测：

Serverless 已经开始从偏离线业务进入在线业务

真正的按请求次数计费和从零到一的响应时间是一个天然的矛盾，以 FaaS 为代表的 Serverless 技术一开始都是从对响应时间不敏感的，事件驱动的偏离线业务入手。但是今天我们已经看到，包括 AWS Lambda Provisioned Capacity 和 Azure Functions Premium plan 在内的产品特性，都在让用户稍微付出一点额外的成本以换取更低的响应时间。这对于在线业务来说，无疑是更适合的。

Serverless 不仅仅是应用或者函数的能力，也会加速推动基础设施和服务 Serverless 化

业务代码托管给 Serverless 平台之后，即能享受到自动弹性，按请求计费能能力。但是如果基础设施和相关服务不具备实时的扩缩容能力，那么对于业务整体来说，就不是弹性的。我们已经看到 AWS 围绕 Lambda 对 VPC 网络、数据库连接池等资源做了大量实时弹性优化，相信其他的厂商也会跟进，进而行业整体会加速基础设施和各类云服务的 Serverless 化。

以 Knative 为代表的开源解决方案会得到越来越多的关注

尽管各个云厂商都在大力推广自己的 Serverless 产品，但是开发者普遍还是会担心被厂商绑定，因此具备一定规模的组织会基于开源方案，如 Knative，搭建自己的 Serverless 平台。而一旦某个开源方案成为主流，云厂商就会主动去兼容开源标准并增大社区投入。

期待 Java 持续进击，成为 Serverless 平台主流语言之一

Serverless 平台要求应用的镜像足够小以能够快速分发，同时要求应用的启动时间极短。虽然在这些方面，Java 和 NodeJS 和 Python 等语言有差距，但是 Java 社区在不断努力。我们看到 Java 通过 Java 9 Modules 以及 GraalVM Native Image 等技术在不断努力“减肥”，主流框架 Spring 也开始拥抱 GraalVM，而新的框架如 Quarkus 和 Micronaut 也在做新的突破。期待 Java 在 Serverless 领域给人焕然一新的感觉。

基于 WebAssembly(简称 WASM) 的 FaaS 方案有望出现

Docker 的创始人之一 Solomon Hykes 曾说，“如果 2008 年有 WASM 和 WASI，我们当时就没有必要创造 Docker 了”，这句话在一定程度上说明了 WASM 的重要性。虽然当下 WASM 更多作为一种运行在浏览器端的技术被人了解，但是它具备非常优秀的安全隔离能力，极快的启动速度，以及对于超过 20 种语言的支持，那么为什么不能让它运行在服务端呢？这些技术特性都非常契合 FaaS 的要求。