伯克利论断：Serverless 是云时代的主宰，未来十年会迅速被采用

来自来自伯克利的犀利断言：Serverless 计算将会成为云时代默认的计算范式，并取代 Serverful （传统云）计算模式。本文对伯克利的论文进行了解读，分析为何 Serverless 将会在接下来的十年迅速被采用，并得到飞速发展。

编者按

来自伯克利的犀利断言：Serverless 计算将会成为云时代默认的计算范式，并取代 Serverful （传统云）计算模式，因此也就意味着服务器 - 客户端模式的终结。

你准备好了吗？

引言

2009 年，伯克利以独特的视角发布了一篇文献，定义了云计算，十年过去了，这篇文章被引用无数，其中的观点更是当下最好的见证：

按需计算的表现形式。

消除云用户的前期承诺。

根据需要在短期内支付使用计算资源的能力。

规模经济，由于许多非常大的数据中心，显着降低了成本。

通过资源虚拟化简化操作并提高利用率。

通过多路复用来承载不同组织的工作负载，进而提高硬件利用率。

2019 年，伯克利又以新的视角发布了一篇文献：《将云中的编程变得简单：伯克利视角下的 Serverless 计算》(https://rise.cs.berkeley.edu/blog/a-berkeley-view-on-serverless-computing/) 观点同样让人眼前一亮：

Serverless 所提供的接口，简化了云计算的编程，其代表了程序员生产力的又一次的变革，一如编程语言从汇编时代演变为高级语言时代。

因为 Serverless 和传统的云计算有着本质的区别：

计算和存储的解耦，彼此独立扩展和定价。

将执行的代码作为运行的对象，而屏弃了分配该段代码所运行的资源。

代码成为明码标价的对象，而不再是运行代码所需要的资源。

如果各位看官和我一样，对于伯克利视角下的 Serverless 好奇的话，不妨跟随我接下来以问答的方式来解读一下这篇文献：

数据中心即计算机。 —— Luiz Barroso（2007）

Serverless 计算的最佳理解是？

在任何的 Serverless 平台，用户只需要使用高级语言撰写使用云功能，然后以事件来触发运行即可，如将图片上传到云存储中、将图像缩略图插入到数据库表中，而所有的传统的操作：实例选择、实例扩展、部署、容错、监控、日志、安全补丁等等，均由 Serverless 计算的来掌控。

Serverless 和传统Serverful 的区别？

相对于 Serverless 计算，传统意义上的云计算已经成为了 Serverful 计算了，以下列表从开发者和系统管理员的角度分别对比了他们二者之间的区别：

基于云环境的描述下，Serverful 计算犹如传统底层的编程语言，如汇编程序；而 Serverless 计算犹如高级的编程语言，如 Python。前者开发者需要考虑每一个细节，到 CPU 寄存器这样一个级别，而后者开发者只需要考虑要实现的功能即可。

Serverless 盛行的基础条件有哪些？

Serverless 计算是在 PaaS 和原来模式的之上的重要创新。

基于 VM 的隔离技术，如 Firecracker 、gVisor 等技术的成熟。

允许云用户携带运行程序所需要的库。

BaaS 的发展，如对象存储的不断完善。

容器技术、Kubernetes 项目的崛起。

边缘计算的迅猛发展需求

伯克利的大胆预言是什么？

Serverless 将会在接下来的十年，迅速的被采用，将会得到飞速的发展。

新的 BaaS 存储服务会被发明，以扩展在 Serverless 计算上能够运行更加适配的应用程序类型。 这样的存储能够与本地块存储的性能相匹配，而且具有临时和持久可供选择。

比现有的 x86 微处理器更多的异构计算机。

更加安全、易用的编程，不仅具有高级语言的抽象能力，还有很好的细粒度的隔离性。

基于 Serverless 计算的价格将低于 Serverful 计算，至少不会高于 Serverful 计算。

Serverless 将会接入更多的后台支撑服务，如 OLTP 数据库、消息队列服务等。

Serverless 计算一旦取得技术上的突破，将会导致 Serverful 服务的下滑。

Serverless 将会成为云时代默认的计算范式，将会取代 Serverful 计算，因此也意味着服务器 - 客户端模式的终结。

Serverless 计算的软件栈架构概览

Serverless 介于基础云平台和应用程序之间，旨在简化基于云的编程开发，Cloud Functions （通常称之为 FaaS）提供通用的计算，辅以专门的后端即服务（BaaS）等生态系统，如对象存储、Key-Value 数据库等。

Serverless 目前应用的场景如何？

来自 2018 年的一个调查显示：

对五类典型应用的深度分析：

对 Serverless 计算的期待？

抽象层：更多的资源调度、增加数据依赖功能

系统：高性能、经济实惠、透明配置的存储，最小化启动时间，协调服务

网络：实现更高吞吐量的通信

安全：随机的调度、物理隔离、细粒度的安全上下文

体系结构：异构性、价格下调、更方便的管理

Serverless 目前被吐槽的地方是？

在分析了五大典型（实时视频解码、MapReduce、大规模线性代数计算、机器学习训练、数据库）应用案例之后，得出如下几个结论：

存储空间不足以进行细粒度操作；

缺乏细粒度的协调；

标准通信模式的性能不佳；

启动的延迟性。

什么吸引着大家去追求 Serverless ？

对于云用户来说：

不需要任何的操作云基础设施、部署等知识，关注功能即可。

更加容易编写应用程序是最主要的动力。

更短的运行时间，毋须关心内存的大小，无状态的天然特性。

省钱

对于云提供商来说：

减少对 X86 服务器的采用，可有效节省成本。

对计算新的抽象，意味着未来的无限可能性。

谬误和陷阱

本章是向 Hennessy and Patterson 二位的风格致敬。鉴于本文只是读论文的解读，所以不会翻译所有的内容，这里仅抛砖引玉，讲述两个非常有趣的答复：

谬误：Cloud Functions 无法处理需要可预测性能的极低延迟应用程序。

Serverful 计算，即服务器实例对于低延迟应用程序的处理，是它们始终处于启动状态，因此它们可以在收到请求时快速回复请求。 那么，照葫芦画瓢，如果 Cloud Functions 的启动延迟对于给定的应用程序来说不够好，可以使用类似的策略：通过定期运行它们来 Cloud Functions 进行预热，从而确保在任何给定时间都能够及时的响应，进而满足传入的请求。

陷阱：Serverless 计算会导致无法预料的成本

这种纯粹意义上按代码运行付费的模式，其实是大家对于这样新的计费模式的不适应罢了，尤其是大型公司的预算考虑，相信随着时间的推移，一旦人们了解了自己的业务以及有了一些历史数据之后，就会适应这样的计算模式的，一如对于如电力这样的计费模式。

笔者能力所限，加上论文论断式的风格，最后强烈建议各位看官请移步伯克利网站下载论文，进行进一步的深度阅读！尤其是引用的材料。

论文链接：https://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-3.pdf

活动推荐