伯克利论断：Serverless 才是云时代的主宰

编者按：

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

你准备好了吗？

引言

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

按需计算的表现形式。
消除云用户的前期承诺。
根据需要在短期内支付使用计算资源的能力。
规模经济，由于许多非常大的数据中心，显着降低了成本。
通过资源虚拟化简化操作并提高利用率。
通过多路复用来承载不同组织的工作负载，进而提高硬件利用率。

2019年，伯克利又以新的视角发布了一篇文献：将云中的编程变得简单：伯克利视角下的Serverless 计算。观点同样让人眼前一亮：

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

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

计算和存储的解耦，彼此独立扩展和定价。
将执行的代码作为运行的对象，而屏弃了分配该段代码所运行的资源。
代码成为明码标价的对象，而不再是运行代码所需要的资源。

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

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

Serverless 计算的最佳理解是？

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

Serverless 计算和传统的云计算（serverful）有何区别？

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

	特性	AWS Serverless 云计算	AWS Serverful 云计算
程序员	何时运行程序	由云用户根据事件自行选择	除非明确停止，否则会一直运行。
	编程语言	JavaScript、Python、Java、Go等有限的语言	任何语言
	程序状态	保存在存储（无状态）	任何地方（有状态或无状态）
	最大内存大小	0.125~3GiB（云用户自行选择）	0.5~1952GiB（云用户自行选择）
	最大本地存储	0.5GiB	0~3600 GiB （云用户自行选择）
	最长运行时间	900秒	随意
	最小计费单元	0.1秒	60秒
	每计费单元价格	$0.0000002	$0.0000867 - $0.4080000
	操作系统和库	云供应商选择	云用户自行选择
系统管理员	服务器实例	云供应商选择	云用户自行选择
	扩展	云供应商负责提供	云用户自己负责
	部署	云供应商负责提供	云用户自己负责
	容错	云供应商负责提供	云用户自己负责
	监控	云供应商负责提供	云用户自己负责
	日志	云供应商负责提供	云用户自己负责

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

Serverless 之所以成为可能的基础条件有哪些？

Serverless 计算是在PaaS和原来模式的之上的重要创新。
基于VM的隔离技术，如Firecracker 、gVisor等技术的成熟。
允许云用户携带运行程序所需要的库。
BaaS 的发展，如对象存储的不断完善。
容器技术、Kubernetes 项目的崛起。
边缘计算的迅猛发展需求

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

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

新的BaaS存储服务会被发明，以扩展在 Serverless 计算上能够运行更加适配的应用程序类型。这样的存储能够与本地块存储的性能相匹配，而且具有临时和持久可供选择。
比现有的 x86 微处理器更多的异构计算机。
更加安全、易用的编程，不仅具有高级语言的抽象能力，还有很好的细粒度的隔离性。
基于Serverless 计算的价格将低于Serverful计算，至少不会高于Serverful计算。
Serverless 将会接入更多的后台支撑服务，如OLTP 数据库、消息队列服务等。
Serverless 计算一旦取得技术上的突破，将会导致Serverful服务的下滑。
Serverless 将会成为云时代默认的计算范式，将会取代 Serverful 计算，因此也意味着服务器-客户端模式的终结。

Serverless 计算的软件栈架构概览

$\"image\"$

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

Serverless 目前应用的场景如何？

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

百分比	用户场景
32%	web 和 API 服务
21%	数据处理，如批处理的ETL
17%	整个第三方的服务
16%	内部 tooling
8%	聊天机器人，如 Alexa Skills（Alexa AI 助手 SDK）
6%	物联网

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

应用程序	描述	挑战	解决办法	花销比较
实时视频压缩（ExCamera）	扔到云中的视频解码	对象存储太慢，无法支持细粒度的通信; 功能太粗糙，无法完成任务。	功能对功能以避免对象存储；以功能调度而不是任务。	比基于虚拟机快60倍，但是钱只花了1/6。
MapReduce	大数据处理（100TB排序）	由于对象存储延迟和IOPS限制，扩展成为问题	使用低延迟存储，高IOPS	比虚拟机快1%，节省15%的费用
线性代数计算（Numpy-wren)	大规模线性代数计算	对象存储的低延迟、难以实现客户端的广播问题。	使用低延时高吞吐的对象存储，	比原来慢了3个数量级，CPU的消耗降低1.26到2.5倍。
机器学习pipeline(Cirrus)	大规模的机器学习	缺乏快速的存储，难以实现广播、聚合问题。	使用低延迟存储，高IOPS	比虚拟机快3~5倍，比原来贵7倍
数据库（Serverless SQLite）	应用程序的主要状态（OLTP）	缺乏共享内存，对象存储具有高延迟，缺乏对入站连接的支持。	如果写入需求低，共享文件系统可以工作。	TPC-C基准，要比原来的快3倍，读取比例匹配但写入不匹配。

对 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