伯克利论断Serverless 是云时代的主宰未来十年会迅速被采用.docx
《伯克利论断Serverless 是云时代的主宰未来十年会迅速被采用.docx》由会员分享，可在线阅读，更多相关《伯克利论断Serverless 是云时代的主宰未来十年会迅速被采用.docx（8页珍藏版）》请在冰豆网上搜索。
伯克利论断Serverless是云时代的主宰未来十年会迅速被采用
来自来自伯克利的犀利断言：
Serverless计算将会成为云时代默认的计算范式，并取代Serverful（传统云）计算模式。
本文对伯克利的论文进行了解读，分析为何Serverless将会在接下来的十年迅速被采用，并得到飞速发展。
编者按
来自伯克利的犀利断言：
Serverless计算将会成为云时代默认的计算范式，并取代Serverful（传统云）计算模式，因此也就意味着服务器-客户端模式的终结。
你准备好了吗？
引言
2009年，伯克利以独特的视角发布了一篇文献，定义了云计算，十年过去了，这篇文章被引用无数，其中的观点更是当下最好的见证：
按需计算的表现形式。
消除云用户的前期承诺。
根据需要在短期内支付使用计算资源的能力。
规模经济，由于许多非常大的数据中心，显着降低了成本。
通过资源虚拟化简化操作并提高利用率。
通过多路复用来承载不同组织的工作负载，进而提高硬件利用率。
2019年，伯克利又以新的视角发布了一篇文献：
《将云中的编程变得简单：
伯克利视角下的Serverless计算》（https:
//rise.cs.berkeley.edu/blog/a-berkeley-view-on-serverless-computing/）观点同样让人眼前一亮：
Serverless所提供的接口，简化了云计算的编程，其代表了程序员生产力的又一次的变革，一如编程语言从汇编时代演变为高级语言时代。
因为Serverless和传统的云计算有着本质的区别：
计算和存储的解耦，彼此独立扩展和定价。
将执行的代码作为运行的对象，而屏弃了分配该段代码所运行的资源。
代码成为明码标价的对象，而不再是运行代码所需要的资源。
如果各位看官和我一样，对于伯克利视角下的Serverless好奇的话，不妨跟随我接下来以问答的方式来解读一下这篇文献：
数据中心即计算机。
——LuizBarroso（2007）
Serverless计算的最佳理解是？
在任何的Serverless平台，用户只需要使用高级语言撰写使用云功能，然后以事件来触发运行即可，如将图片上传到云存储中、将图像缩略图插入到数据库表中，而所有的传统的操作：
实例选择、实例扩展、部署、容错、监控、日志、安全补丁等等，均由Serverless计算的来掌控。
Serverless和传统Serverful的区别？
相对于Serverless计算，传统意义上的云计算已经成为了Serverful计算了，以下列表从开发者和系统管理员的角度分别对比了他们二者之间的区别：
特性
AWSServerless云计算
AWSServerful云计算
程序员
何时运行程序
由云用户根据事件自行选择
除非明确停止，否则会一直运行。
编程语言
JavaScript、Python、Java、Go等有限的语言
任何语言
程序状态
保存在存储（无状态）
任何地方（有状态或无状态）
最大内存大小
0.125~3GiB（云用户自行选择）
0.5~1952GiB（云用户自行选择）
最大本地存储
0.5GiB
0~3600GiB（云用户自行选择）
最长运行时间
900秒
随意
最小计费单元
0.1秒
60秒
每计费单元价格
$0.0000002
$0.0000867-$0.4080000
操作系统和库
云供应商选择
云用户自行选择
系统管理员
服务器实例
云供应商选择
云用户自行选择
扩展
云供应商负责提供
云用户自己负责
部署
云供应商负责提供
云用户自己负责
容错
云供应商负责提供
云用户自己负责
监控
云供应商负责提供
云用户自己负责
日志
云供应商负责提供
云用户自己负责
基于云环境的描述下，Serverful计算犹如传统底层的编程语言，如汇编程序；而Serverless计算犹如高级的编程语言，如Python。
前者开发者需要考虑每一个细节，到CPU寄存器这样一个级别，而后者开发者只需要考虑要实现的功能即可。
Serverless盛行的基础条件有哪些？
Serverless计算是在PaaS和原来模式的之上的重要创新。
基于VM的隔离技术，如Firecracker、gVisor等技术的成熟。
允许云用户携带运行程序所需要的库。
BaaS的发展，如对象存储的不断完善。
容器技术、Kubernetes项目的崛起。
边缘计算的迅猛发展需求
1.
伯克利的大胆预言是什么？
Serverless将会在接下来的十年，迅速的被采用，将会得到飞速的发展。
新的BaaS存储服务会被发明，以扩展在Serverless计算上能够运行更加适配的应用程序类型。
这样的存储能够与本地块存储的性能相匹配，而且具有临时和持久可供选择。
比现有的x86微处理器更多的异构计算机。
更加安全、易用的编程，不仅具有高级语言的抽象能力，还有很好的细粒度的隔离性。
基于Serverless计算的价格将低于Serverful计算，至少不会高于Serverful计算。
Serverless将会接入更多的后台支撑服务，如OLTP数据库、消息队列服务等。
Serverless计算一旦取得技术上的突破，将会导致Serverful服务的下滑。
Serverless将会成为云时代默认的计算范式，将会取代Serverful计算，因此也意味着服务器-客户端模式的终结。
Serverless计算的软件栈架构概览
Serverless介于基础云平台和应用程序之间，旨在简化基于云的编程开发，CloudFunctions（通常称之为FaaS）提供通用的计算，辅以专门的后端即服务（BaaS）等生态系统，如对象存储、Key-Value数据库等。
Serverless目前应用的场景如何？
来自2018年的一个调查显示：
百分比
用户场景
32%
web和API服务
21%
数据处理，如批处理的ETL
17%
整个第三方的服务
16%
内部tooling
8%
聊天机器人，如AlexaSkills（AlexaAI助手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倍
数据库（ServerlessSQLite）
应用程序的主要状态（OLTP）
缺乏共享内存，对象存储具有高延迟，缺乏对入站连接的支持。
如果写入需求低，共享文件系统可以工作。
TPC-C基准，要比原来的快3倍，读取比例匹配但写入不匹配。
对Serverless计算的期待？
抽象层：
更多的资源调度、增加数据依赖功能
系统：
高性能、经济实惠、透明配置的存储，最小化启动时间，协调服务
网络：
实现更高吞吐量的通信
安全：
随机的调度、物理隔离、细粒度的安全上下文
体系结构：
异构性、价格下调、更方便的管理
Serverless目前被吐槽的地方是？
在分析了五大典型（实时视频解码、MapReduce、大规模线性代数计算、机器学习训练、数据库）应用案例之后，得出如下几个结论：
存储空间不足以进行细粒度操作；
缺乏细粒度的协调；
标准通信模式的性能不佳；
启动的延迟性。
什么吸引着大家去追求Serverless？
对于云用户来说：
不需要任何的操作云基础设施、部署等知识，关注功能即可。
更加容易编写应用程序是最主要的动力。
更短的运行时间，毋须关心内存的大小，无状态的天然特性。
省钱
对于云提供商来说：
减少对X86服务器的采用，可有效节省成本。
对计算新的抽象，意味着未来的无限可能性。
谬误和陷阱
本章是向HennessyandPatterson二位的风格致敬。
鉴于本文只是读论文的解读，所以不会翻译所有的内容，这里仅抛砖引玉，讲述两个非常有趣的答复：
谬误：
CloudFunctions无法处理需要可预测性能的极低延迟应用程序。
Serverful计算，即服务器实例对于低延迟应用程序的处理，是它们始终处于启动状态，因此它们可以在收到请求时快速回复请求。
那么，照葫芦画瓢，如果CloudFunctions的启动延迟对于给定的应用程序来说不够好，可以使用类似的策略：
通过定期运行它们来CloudFunctions进行预热，从而确保在任何给定时间都能够及时的响应，进而满足传入的请求。
陷阱：
Serverless计算会导致无法预料的成本
这种纯粹意义上按代码运行付费的模式，其实是大家对于这样新的计费模式的不适应罢了，尤其是大型公司的预算考虑，相信随着时间的推移，一旦人们了解了自己的业务以及有了一些历史数据之后，就会适应这样的计算模式的，一如对于如电力这样的计费模式。
笔者能力所限，加上论文论断式的风格，最后强烈建议各位看官请移步伯克利网站下载论文，进行进一步的深度阅读！
尤其是引用的材料。
论文链接：
https:
//www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-3.pdf
升级会员 