来自伯克利的犀利断言：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.5GiB0~3600 GiB （云用户自行选择）最长运行时间900 秒随意最小计费单元0.1 秒60 秒每计费单元价格$0.00000020.0000867−
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 计算的软件栈架构概览
Serverless 介于基础云平台和应用程序之间，旨在简化基于云的编程开发，Cloud Functions （通常称之为 FaaS）提供通用的计算，辅以专门的后端即服务（BaaS）等生态系统，如对象存储、Key-Value 数据库等。
Serverless 目前应用的场景如何？来自 2018 年的一个调查显示：
百分比用户场景32%web 和 API 服务21%数据处理，如批处理的 ETL17%整个第三方的服务16%内部 tooling8%聊天机器人，如 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 计算会导致无法预料的成本
这种纯粹意义上按代码运行付费的模式，其实是大家对于这样新的计费模式的不适应罢了，尤其是大型公司的预算考虑，相信随着时间的推移，一旦人们了解了自己的业务以及有了一些历史数据之后，就会适应这样的计算模式的，一如对于如电力这样的计费模式。
笔者能力所限，加上论文论断式的风格，最后强烈建议各位看官请移步伯克利网站下载论文，进行进一步的深度阅读！尤其是引用的材料。
论文链接：
