Abstract

无服务器云计算几乎处理所有系统管理操作，使程序员更容易使用云。它提供了一个极大简化云编程的接口，代表了从汇编语言到高级编程语言的过渡。本文简要介绍了云计算的历史，包括对2009年伯克利云计算视图的预测进行了说明，解释了无服务器计算的动机，描述了扩展无服务器当前限制的应用程序，然后列出了障碍和研究机会无服务器计算需要充分发挥其潜力。就像2009年的论文确定了云的挑战并预测它们将得到解决以及云的使用会加速一样，我们预测这些问题是可以解决的，无服务器计算将成为云计算未来的主导。

1. Introduction to Serverless Computing

2009年，为了帮助解释围绕云计算的兴奋，“伯克利云计算视图”[2]确定了六个潜在优势：

1.按需提供无限计算资源。

2.消除云用户的前期承诺。

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

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

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

6.通过复用来自不同组织的工作负载来提高硬件利用率。

在过去的十年中，这些优势已经基本实现，但云用户继续承担复杂运营的负担，许多工作负载仍然无法从高效的多路复用中受益。这些不足主要与未能实现最后两个潜在优势相对应。云计算减轻了物理基础设施管理的用户，但却为他们提供了大量的虚拟资源来管理。多路复用适用于批处理工作负载，例如MapReduce或高性能计算，可以充分利用他们分配的实例。它对于有状态服务的效果较差，例如将数据库管理系统等企业软件移植到云中时。

2009年，云中存在两种相互竞争的虚拟化方法。作为论文解释：

亚马逊EC2处于频谱的一端。 EC2实例看起来很像物理硬件，用户可以从内核向上控制几乎整个软件堆栈。 …...另一个极端的应用领域特定平台，例如Google App Engine …...强制实施无状态计算层和有状态存储层之间清晰分离的应用程序结构。 App Engine令人印象深刻的自动扩展和高可用性机制…...依赖于这些限制。

市场最终采用了亚马逊的低级虚拟机云计算方法，因此谷歌，微软和其他云计算公司提供了类似的界面。我们认为，低级虚拟机成功的主要原因是，在云计算的早期阶段，用户希望在云中重建与他们在本地计算机上相同的计算环境，以简化将工作负载移植到云[3-6]。理所当然地，这种实际需求优先于仅为云编写新程序，特别是因为不清楚云的成功程度。

这种选择的缺点是开发人员必须自己管理虚拟机，基本上要么成为系统管理员，要么与他们一起设置环境。表1列出了在云中运行环境必须管理的问题。长期的低级虚拟机管理职责列表激发了客户使用更简单的应用程序，以便为新应用程序提供更轻松的云路径。例如，假设应用程序想要将镜像从电话应用程序发送到云，这应该创建缩略图镜像然后将它们放在Web上。完成这些任务的代码可能是几十行JavaScript，与使用适当的环境来运行代码来设置服务器相比，这将是一个微不足道的开发。

对这些需求的认识导致2015年亚马逊推出了一项名为AWS Lambda服务的新选项。 Lambda提供了云功能，并引起了对无服务器计算的广泛关注。虽然无服务器计算可以说是一种矛盾 - 你仍然在使用服务器进行计算 - 这个名称可能会被卡住，因为它表明云用户只需编写代码并将所有服务器配置和管理任务留给云提供商。虽然云功能 - 打包为FaaS（功能即服务）产品 - 代表无服务器计算的核心，但云平台还提供专门的无服务器框架，满足特定的应用需求，如BaaS（后端即服务）产品[7]。简而言之，无服务器计算= FaaS + BaaS.3在我们的定义中，对于服务被视为无服务器，它必须自动扩展而无需显式配置，并根据使用情况进行计费。在本文的其余部分，我们将重点关注云功能的出现，发展和未来。云功能是当今无服务器计算中的通用元素，并引领着云的简化和通用编程模型。

接下来，我们将激励并定义无服务器计算。与最初的关于云计算的Berkeley View论文一样，我们列出了无服务器计算需要解决的挑战和研究机会，以实现其承诺。虽然我们不确定哪些解决方案会赢，但我们相信所有问题都将最终得到解决，从而使无服务器计算成为云计算的代表。

2. Emergence of Serverless Computing

在任何无服务器平台中，用户只需用高级语言编写云功能，选择应触发功能运行的事件 - 例如将图像加载到云存储中或将图像缩略图添加到数据库表中 - 让无服务器系统处理其他所有事情：实例选择，扩展，部署，容错，监视，日志记录，安全补丁等。表2总结了无服务器和传统方法之间的区别，我们在本文中称之为服务器云计算。请注意，这两种方法代表了基于函数/服务器中心的计算平台的连续体的端点，其中集成化的编排框架如Kubernetes代表了中间体。

图1说明了无服务器如何通过使云资源更易于使用来简化应用程序开发。在云环境中，服务器计算就像用低级汇编语言编程，而无服务器计算就像用Python等高级语言编程。计算简单表达式（如c = a + b）的汇编语言程序员必须选择一个或多个要使用的寄存器，将值加载到这些寄存器中，执行算术运算，然后存储结果。这反映了服务器云编程的几个步骤，其中首先提供资源或识别可用的资源，然后使用必要的代码和数据加载这些资源，执行计算，返回或存储结果，并最终管理资源释放。无服务器计算的目标和机会是为云程序员提供类似于向高级编程语言过渡的优势.高级编程环境的其他功能在无服务器计算中也有自然的相似之处。自动内存管理减轻了程序员管理内存资源的负担，而无服务器计算使程序员无法管理服务器资源。

准确地说，无服务器和服务器计算之间存在三个关键区别：

1.解耦计算和存储。存储和计算分别单独提供和定价。通常，存储由单独的云服务提供，并且计算是无状态的。

2.在不管理资源分配的情况下执行代码。用户不是请求资源，而是提供一段代码，云自动提供资源来执行该代码。

3.按比例使用的资源支付，而不是分配资源。计费是与执行相关联的某些维度，例如执行时间，而不是基础云平台的维度，例如分配的VM的大小和数量。

2.1 Contextualizing Serverless Computing

需要哪些技术突破才能实现无服务器计算？有人认为无服务器计算仅仅是对先前产品的重新定义，可能是平台即服务（PaaS）云产品（如Heroku [8]，Firebase [9]或Parse [10]）的适度概括。其他人可能会指出，20世纪90年代流行的共享Web托管环境提供了无服务器计算所提供的大部分内容。例如，它们有一个无状态编程模型，允许高水平的多租户，对可变需求的弹性响应，以及标准化的函数调用API，即公共网关接口（CGI）[11]，它甚至允许直接部署写入的源代码在Perl或PHP等高级语言中。谷歌的原始App Engine在无服务器计算普及之前几年被市场拒绝，也允许开发人员部署代码，同时将大多数操作方面留给云提供商。我们相信无服务器计算代表了PaaS和其他先前型号的重大创新。

今天，具有云功能的无服务器计算与其前代产品的不同之处在于几个基本方面：更好的自动扩展，强大的隔离，平台灵活性和服务生态系统支持。 在这些因素中，AWS Lambda提供的自动缩放标记与以前的标记有明显的不同。它以比服务器自动缩放技术更高的保真度跟踪负载，在需要时快速响应扩展，并在没有需求的情况下一直缩减到零资源和零成本。它以更细粒度的方式收费，在按小时计费的其他自动调节服务时提供100毫秒的最小计费增量.8在关键的离开时，它向客户收取其代码实际执行时间的费用，不是为执行他们的程序保留的资源。这种区别确保云提供商在自动缩放中具有“游戏中的皮肤”，从而提供了确保有效资源分配的激励。

无服务器计算依赖于强大的性能和安全隔离，使多租户硬件共享成为可能。类似VM的隔离是云功能多租户硬件共享的当前标准[12]，但由于VM配置可能需要很长时间，因此无服务器计算提供商使用复杂的技术来加速功能执行环境的创建。 AWS Lambda中反映的一种方法是维护仅需要分配给租户的VM实例的“热池”，以及之前用于运行功能并维护以服务于未来的实例的“活动池”调用[13]。实现高利用率所必需的资源生命周期管理和多租户仓包装是无服务器计算的关键技术推动者。我们注意到，最近的一些提案旨在通过利用容器，unikernel，库操作系统或语言VM来减少提供多租户隔离的开销。例如，Google宣布gVisor [14]已被App Engine，Cloud Functions和Cloud ML Engine采用，亚马逊发布了用于AWS Lambda和AWS Fargate的Firecracker VM [15]，而CloudFlare Workers无服务器平台提供了多个使用Web浏览器沙盒技术在JavaScript云功能之间进行租户隔离[16]。

其他一些区别帮助无服务器计算成功。通过允许用户使用自己的库，无服务器计算可以支持比与特定用例紧密相关的PaaS服务更广泛的应用程序。无服务器计算在现代数据中心中运行，并且比旧的共享Web托管环境以更大的规模运行。如第1节所述，云功能（即FaaS）推广了无服务器范例。

但是，值得承认的是，他们的成功部分归功于自公共云开始以来存在的BaaS产品，如AWS S3等服务。在我们看来，这些服务是特定于域的，高度优化的无服务器计算实现。云功能以更一般的形式表示无服务器计算。我们通过比较几种服务的编程接口和成本模型，总结了表3中的这一观点

用于部署微服务的“容器编排”技术。与无服务器计算不同，Kubernetes是一种简化服务器计算管理的技术。源于谷歌内部使用多年的发展[18]，它正在迅速普及。 Kubernetes可以提供短期计算环境，例如无服务器计算，并且具有很少的限制，例如，关于硬件资源，执行时间和网络通信。它还可以完全在公共云上部署最初为内部部署使用而开发的软件，几乎不做任何修改。另一方面，无服务器计算引入了一种范式转换，允许将操作职责完全卸载到提供者，并使细粒度多租户多路复用成为可能。托管的Kubernetes产品，例如Google Kubernetes Engine（GKE）和AWS Elastic Kubernetes Service（EKS）在这个连续体中提供了一个中间立场：它们卸载了Kubernetes的运营管理，同时为开发人员提供了配置任意容器的灵活性。托管Kubernetes服务和无服务器计算之间的一个关键区别是计费模型。前者按预留资源收费，而后者按功能执行持续时间收费。

Kubernetes也是混合应用程序的完美搭档，其中一部分在本地硬件上运行，一部分在云中运行。我们的观点是，这种混合应用程序在向云的过渡中是有意义的。然而，从长远来看，我们相信云规模经济，更快的网络带宽，不断增长的云服务以及通过无服务器计算简化云管理将降低此类混合应用的重要性。边缘计算是PostPC时代云计算的合作伙伴，虽然我们关注的是无服务器计算将如何改变数据中心内的编程，但也有可能在边缘产生影响。多个内容分发网络（CDN）运营商提供了在靠近用户[19,20]的设施中执行无服务器功能的能力，无论他们在哪里，AWS IoT Greengrass [21]甚至可以在边缘设备中嵌入无服务器执行。现在我们已经定义了无服务器计算和上下文化，让我们看看为什么它对云提供商，云用户和研究人员具有吸引力。

2.2 Attractiveness of Serverless Computing

对于云提供商而言，无服务器计算可促进业务增长，因为使云更容易编程有助于吸引新客户并帮助现有客户更多地使用云产品。例如，最近的调查发现，大约24％的无服务器用户不熟悉云计算[22]，30％的现有服务器云客户也使用无服务器计算[23]。此外，短时间，小内存占用和无状态特性通过使云提供商更容易找到运行这些任务的未使用资源来改善统计复用。云提供商也可以使用不那么受欢迎的计算机 - 因为实例类型取决于云提供商 - 例如旧服务器，这些服务器可能对服务器云客户的吸引力较小。这两项福利都会增加现有资源的收入。

客户受益于提高的编程生产力，并且在许多情况下也可以节省成本，这是底层服务器利用率更高的结果。即使无服务器计算让客户更有效率，Jevons悖论[24]表明他们将增加对云的使用，而不是削减，因为更高的效率将增加用户的需求。

无服务器还提高了x86机器代码的云部署水平--99％的云计算机使用x86指令集 - 高级编程语言，9支持架构创新。如果ARM或RISC-V提供比x86更好的性价比，则无服务器计算可以更轻松地更改指令集。云提供商甚至可以接受语言定位优化和特定领域架构的研究，这些架构专门用于加速用Python等语言编写的程序[25]（参见第4节）。

云用户喜欢无服务器计算，因为新手可以在不了解云基础架构的情况下部署功能，因为专家可以节省开发时间并专注于应用程序独有的问题。无服务器用户可以节省资金，因为只有在事件发生时才执行功能，细粒度会计（现在通常为100毫秒）意味着他们只为他们使用的东西而不是他们保留的东西付费。表4显示了当今无服务器计算的最流行用途。

研究人员已经被无服务器计算，尤其是云计算功能所吸引，因为它是一种新的通用计算抽象，有望成为云计算的未来，并且因为有很多机会可以提升当前性能并克服当前的局限性。

3. Limitations of Today’s Serverless Computing Platforms Serverless

无服务器云功能已成功用于多类工作负载，包括API服务，事件流处理和有限的ETL（参见表3）。为了了解哪些障碍阻碍了支持更多的一般工作负载，我们尝试创建我们感兴趣的无服务器版本的应用程序，并研究其他人发布的示例。这些无意代表当前无服务器计算生态系统之外的其他信息技术; 它们只是为了发现可能阻止许多其他有趣应用程序的无服务器版本的常见弱点而选择的示例。

在本节中，我们概述了五个研究项目，并讨论了阻碍现有无服务器计算平台实现最先进性能的障碍，即为相同工作负载匹配服务器云的性能。我们特别关注利用通用云计算功能进行计算的方法，而不是过分依赖其他特定于应用程序的无服务器产品（BaaS）。然而，在我们的最后一个例子，无服务器SQLite中，我们确定了一个用于映射如此糟糕的FaaS的用例，我们得出的结论是数据库和其他状态繁重的应用程序将保留为BaaS。本文末尾的附录详细介绍了每个应用程序。

有趣的是，即使这种折衷的应用程序组合也暴露了类似的弱点，我们在描述应用程序后列出了这些弱点。表5总结了五种应用。

ExCamera：实时视频编码。 ExCamera [26]旨在为用户上传视频到YouTube等网站提供实时编码服务。根据视频的大小，今天的编码解决方案可能需要几十分钟甚至几小时。为了实时执行编码，ExCamera并行化编码的“慢”部分，并连续执行“快速”部分。 ExCamera公开了视频编码器和解码器的内部状态，允许使用纯函数语义执行编码和解码任务。特别地，每个任务将内部状态与视频帧一起作为输入，并将修改的内部状态作为输出发出。

MapReduce： MapReduce，Hadoop和Spark等分析框架传统上部署在托管集群上。虽然其中一些分析工作负载现在转向无服务器计算，但这些工作负载主要由仅映射作业组成。自然的下一步是支持完全成熟的MapReduce工作。这项工作背后的驱动力之一是利用无服务器计算的灵活性来有效地支持资源需求在执行期间显着变化的作业。

Cirrus：机器学习培训。机器学习（ML）研究人员传统上使用VM群集来处理ML工作流程中的不同任务，例如预处理，模型训练和超参数调整。这种方法的一个挑战是该管道的不同阶段可能需要显着不同的资源量。与线性代数算法一样，固定的簇大小将导致严重的未充分利用或严重的减速。无服务器计算可以通过扩展每个阶段来满足其资源需求来应对这一挑战。此外，它使开发人员免于管理集群。

Serverless SQLite：数据库。各种自动调节数据库服务已经存在[28-33]，但为了更好地理解无服务器计算的局限性，了解是什么使数据库工作负载实施起来特别具有挑战性非常重要。在这种情况下，我们考虑第三方是否可以使用云功能（通用无服务器计算构建模块）直接实现无服务器数据库。一个简单的解决方案是在云功能中运行常见的事务数据库，例如PostgreSQL，Oracle或MySQL。然而，这立即遇到了许多挑战。首先，无服务器计算没有内置的持久存储，因此我们需要利用一些远程持久存储，这会带来大的延迟。其次，这些数据库假定面向连接的协议，例如，数据库作为接受来自客户端的连接的服务器运行。此假设与在网络地址转换器后面运行的现有云功能冲突，因此不支持传入连接。最后，虽然许多高性能数据库依赖于共享内存[34]，但云功能是孤立运行的，因此无法共享内存。虽然无共享分布式数据库[35-37]不需要共享内存，但它们希望节点保持在线并可直接寻址。所有这些问题都对在无服务器计算上运行传统数据库软件或实现等效功能提出了重大挑战，因此我们希望数据库保持为BaaS。

这些应用程序希望使用无服务器计算的关键原因之一是细粒度自动缩放，因此资源利用率与每个应用程序的不同需求密切匹配。 表5总结了这五个应用程序的特性，挑战和变通方法，我们接下来用它来确定当前无服务器计算状态的四个限制。

3.1 Inadequate storage for fine-grained operations

无服务器平台的无状态特性使得难以支持具有细粒度状态共享需求的应用程序。这主要是由于云提供商提供的现有存储服务的限制。表6总结了现有云存储服务的属性。

对象存储服务（如AWS S3，Azure Blob存储和Google云存储）具有高度可扩展性，可提供廉价的长期对象存储，但具有较高的访问成本和较高的访问延迟。根据最近的测试，所有这些服务至少需要10毫秒才能读取或写入小物体[38]。关于IOPS，在最近的限制增加[39]之后，S3提供了高吞吐量，但它带来了高成本。维持100K IOPS的成本为30美元/分钟[40]，比运行AWS ElastiCache实例多出3到4个数量级[41]。这样的Elasti-Cache实例在多个轴上提供了更好的性能，具有亚毫秒读写延迟，并且一个实例配置为运行单线程Redis服务器，IOPS超过100K。

键值数据库，例如AWS DynamoDB，Google Cloud Datastore或Azure Cosmos DB提供高IOPS，但价格昂贵且可能需要很长时间才能扩展.最后，虽然云提供商提供基于流行的内存存储实例像Memcached或Redis这样的开源项目，它们不具有容错能力，并且不像无服务器计算平台那样自动缩放。

从表5中可以看出，构建在无服务器基础架构上的应用程序需要具有透明配置的存储服务，该存储等效于计算机自动扩展。不同的应用程序可能会激发对持久性和可用性的不同保证，也可能是延迟或其他性能测量。我们认为这需要开发短暂且持久的无服务器存储选项，我们将在第4节进一步讨论。

3.2 Lack of fine-grained coordination

为了扩展对有状态应用程序的支持，无服务器框架需要为任务提供协调的方法。例如，如果任务A使用任务B的输出，则必须有一种方法让A知道其输入何时可用，即使A和B驻留在不同的节点上也是如此。许多旨在确保数据一致性的协议也需要类似的协调。
现有的云存储服务都没有通知功能。虽然云提供商确实提供独立的通知服务，例如SNS [42]和SQS [43]，但这些服务会增加显着的延迟，有时会增加数百毫秒。而且，当用于细粒度协调时，它们可能是昂贵的。已经有一些拟议的研究系统如Pocket [44]没有很多这些缺点，但它们尚未被云提供商采用。

因此，应用程序别无选择，只能（1）管理提供通知的基于VM的系统，如ElastiCache和SAND [45]，或者（2）实现自己的通知机制，例如ExCamera [26] ]，使云功能能够通过长时间运行的基于VM的集合点服务器相互通信。此限制还表明，无服务器计算的新变体可能值得探索，例如命名函数实例并允许直接寻址以访问其内部状态（例如，Actors as a Service [46]）。

3.3 Poor performance for standard communication patterns

Broadcast，aggregation和 shuffle是分布式系统中最常见的通信原语。这些操作通常用于机器学习培训和大数据分析等应用程序。图2显示了基于VM和基于功能的解决方案的这些原语的通信模式。

使用基于VM的解决方案，在同一实例上运行的所有任务可以共享正在广播的数据的副本，或者在将部分结果发送到其他实例之前执行本地聚合。因此，广播和聚合操作的通信复杂性是O（N），其中N是系统中VM实例的数量。但是，对于云功能，此复杂性为O（N×K），其中K是每个VM的功能数。洗牌操作的差异更为显着。使用基于VM的解决方案，所有本地任务都可以组合其数据，以便两个VM实例之间只有一条消息。假设相同数量的发送者和接收者产生N消息。为了比较，使用云功能我们需要发送（N×K）条消息。由于现有功能的核心数量远少于VM，因此K的范围通常为10到100.由于应用程序无法控制云功能的位置，因此无服务器计算应用程序可能需要发送两个和四个数量级的数据而不是基于VM的等效解决方案。

3.4 Predictable Performance

尽管云功能的启动延迟比传统的基于VM的实例低得多，但启动新实例时产生的延迟对于某些应用程序来说可能很高。影响此冷启动延迟的因素有三个：（1）启动云功能所需的时间; （2）初始化函数的软件环境所花费的时间，例如，加载Python库; （3）用户代码中特定于应用程序的初始化。后两者可以使前者相形见绌。虽然启动云功能可能不到一秒钟，但加载所有应用程序库可能需要几十秒。

可预测性能的另一个障碍是硬件资源的可变性，这是由于云提供商可以灵活地选择底层服务器。在我们的实验[47]中，我们有时会收到来自不同硬件代的CPU。这种不确定性暴露了云提供商希望最大限度地利用其资源和可预测性之间的基本权衡。

4. What Serverless Computing Should Become

现在我们已经解释了今天的无服务器计算及其局限性，让我们展望未来，了解如何将其优势带给更多应用程序。研究人员已经开始解决上面提出的问题，并探讨如何改进无服务器平台以及在其上运行的工作负载的性能[48,49]。我们的伯克利同事和我们中的一些人所做的额外工作强调以数据为中心的分布式系统，机器学习以及编程模型的挑战和无服务器计算的机会[50]。在这里，我们广泛地考虑增加适用于无服务器计算的应用程序和硬件类型，确定五个领域的研究挑战：抽象，系统，网络，安全性和架构。

4.1 Abstraction challenges

Resource Requirement：通过今天的无服务器产品，开发人员可以指定云功能的内存大小和执行时间限制，而不是其他资源需求。这种抽象阻碍了那些想要更多控制指定资源的人，例如CPU，GPU或其他类型的加速器。一种方法是使开发人员能够明确指定这些资源需求。但是，这会使云提供商更难通过统计复用实现高利用率，因为它会对功能调度施加更多限制。通过增加云应用程序开发人员的管理开销，它也违背了无服务器的精神。

更好的选择是提高抽象级别，让云提供者推断资源需求，而不是让开发人员指定它们。为此，云提供商可以使用各种方法，从静态代码分析，分析以前的运行，到动态（重新）编译，以将代码重新定位到其他体系结构。自动配置适当数量的内存特别有吸引力，但当解决方案必须与高级语言运行时使用的自动垃圾收集进行交互时尤其具有挑战性。一些研究表明，这些语言运行时可以与无服务器平台集成[51]。

Data dependencies：今天的云功能平台不了解云功能之间的数据依赖性，更不用说这些功能可能交换的数据量。这种无知可能会导致次优放置，从而导致通信模式效率低下，如MapReduce和numpywren示例所示（参见第3节和附录）。

解决这一挑战的一种方法是让云提供商公开API，允许应用程序指定其计算图，从而实现更好的布局决策，从而最大限度地减少通信并提高性能。我们注意到许多通用分布式框架（例如，MapReduce，Apache Spark和Apache Beam / Cloud Dataflow [52]），并行SQL引擎（例如，BigQuery，Azure Cosmos DB）以及编排框架（例如，Apache Airflow [ 53]）已经在内部生成这样的计算图。原则上，可以修改这些系统以在云功能上运行并将其计算图暴露给云提供商。请注意，AWS Step Functions通过提供状态机语言和API来表示此方向的进展。

4.2 System challenges

高性能，经济实惠，透明配置的存储：如第3节和表5所述，我们看到了两个不同的无需解决的存储需求：无服务器短暂存储和无服务器持久存储。

Ephemeral Storage。第3节中的前四个应用程序受限于用于在云功能之间传输状态的存储系统的速度和延迟。虽然它们的容量需求各不相同，但在应用程序生命周期内，所有这些都需要这样的存应用程序完成后，可以丢弃状态。这种短暂存储也可以配置为其他应用程序中的缓存。

为无服务器应用程序提供短暂存储的一种方法是使用优化的网络堆栈构建分布式内存服务，以确保微秒级延迟。 该系统将使应用程序的功能能够在应用程序的生命周期内有效地存储和交换状态。这种内存服务需要根据应用程序的需求自动扩展存储容量和IOPS。这种服务的一个独特方面是它不仅需要透明地分配内存，还要透明地释放内存。特别是，当应用程序终止或失败时，应自动释放分配给该应用程序的存储。此管理类似于操作系统在进程完成（或崩溃）时自动释放进程分配的资源。此外，此类存储必须跨应用程序提供访问保护和性能隔离。

RAMCloud [54]和FaRM [55]表明，可以构建内存存储系统，可以提供微秒级别的延迟，并支持每个实例数十万IOPS。他们通过仔细优化整个软件堆栈并利用RDMA来最小化延迟来实现这一性能。但是，它们要求应用程序明确配置存储。它们也不能在多个租户之间提供强大的隔离。最近的另一项努力，Pocket [44]，旨在提供短暂存储的抽象，但也缺乏自动缩放，要求应用程序先验地分配存储。

通过利用统计复用，这种短暂的存储可以比现在的服务器计算更具内存效率。通过服务器计算，如果应用程序需要的内存少于分配的VM实例的聚合内存，那么该内存就会浪费掉。相反，对于共享的内存服务，一个无服务器应用程序未使用的任何内存都可以分配给另一个。事实上，统计多路复用甚至可以使单个应用程序受益：使用服务器计算，VM的未使用内存不能被属于同一应用程序的另一个VM上运行的程序使用，而在共享内存服务的情况下，能够。当然，即使使用无服务器计算，如果云功能不使用其整个本地内存，也可能存在内部碎片。在某些情况下，将云功能的应用程序状态存储在共享的内存服务中可以减轻内部内存碎片的后果。

Durable Storage。与其他应用程序一样，我们的无服务器数据库应用程序实验受到存储系统的延迟和IOPS的限制，但它还需要长期数据存储和文件系统的可变状态语义。虽然数据库功能（包括OLTP）可能会越来越多地作为BaaS产品提供，但我们将此应用程序视为几个应用程序的代表，这些应用程序需要比无服务器临时存储更适合提供的更长保留和更高的持久性。要实现高性能无服务器持久存储，一种方法是利用基于SSD的分布式存储与分布式内存缓存配对。最近实现其中许多目标的系统是Anna键值数据库，它通过组合多个现有云存储产品来实现成本效率和高性能[56]。考虑到内存缓存容量可能远低于SSD容量这一事实，这种设计的一个关键挑战是在存在重尾访问分布的情况下实现低尾部延迟。利用新的存储技术[57]，承诺微秒级访问时间，正在成为应对这一挑战的有前途的方法。

与无服务器短暂存储类似，此服务应透明配置，并应确保跨应用程序和租户隔离，以确保安全性和可预测的性能。但是，无应用程序短暂存储将在应用程序终止时回收资源，而无服务器持久存储必须仅显式释放资源（例如，作为“删除”或“删除”命令的结果），就像在传统存储系统中一样。此外，它当然必须确保持久性，以便任何已确认的写入将在失败后存在。

Coordination/signaling service：功能之间的共享状态通常使用生产者 - 消费者设计模式，这需要消费者在生产者可以获得数据时立即知道。类似地，当条件变得可用时，一个函数可能想要发信号通知另一个函数，或者多个函数可能想要协调，例如，以实现数据一致性机制。这种信令系统将受益于微秒级延迟，可靠传递以及广播或群组通信。我们还注意到，由于云函数实例不能单独寻址，因此它们不能用于实现教科书分布式系统算法，如共识或领导者选举[50]。

Minimize startup time：启动时间有三个部分（1）调度和启动资源以运行云功能，（2）下载应用软件环境（例如，操作系统，库）以运行功能代码，以及（3）执行特定于应用程序的启动任务，例如加载和初始化数据结构和库。资源调度和初始化可能会因创建隔离的执行环境以及配置客户的VPC和IAM策略而产生显着的延迟和开销。云提供商[14,15]以及其他[58,59]最近致力于通过开发新的轻量级隔离机制来缩短启动时间。

减少（2）的一种方法是利用单核[60]。 Unikernel以两种方式消除传统操作系统产生的开销。首先，代替动态检测硬件，应用用户配置和分配传统操作系统等数据结构，unikernel通过预先配置它们运行的硬件并静态分配数据结构来压缩这些成本。其次，unikernel仅包括应用程序严格要求的驱动程序和系统库，这导致比传统操作系统更小的占用空间。值得注意的是，由于unikernel是针对特定应用程序量身定制的，因此在运行标准化内核的许多实例时，它们无法实现一些可能的效率，例如在同一VM上的不同云功能之间共享内核代码页，或者减少启动时间通过预缓存来节省时间。减少（2）的另一种方法是在应用程序调用库时动态地和递增地加载库，例如，由Azure Functions中使用的共享文件系统启用。

特定于应用程序的初始化（3）是程序员的责任，但云提供程序可以在其API中包含准备就绪信号，以避免在开始处理函数之前将工作发送到函数实例[61]。更广泛地说，云提供商可以提前执行启动任务[59]。这对于客户无关的任务尤为强大，例如使用流行的操作系统和一组库来启动VM，因为这些实例的“热池”可以在租户之间共享[13]。

4.3 Networking challenges

如第3节所述，如图2所示，云功能可能会对流行的通信原语（如广播，聚合和混洗）产生巨大的开销。特别是，假设我们可以在VM实例上打包K个云功能，云功能版本将发送比实例版本多K倍的消息，并且在shuffle的情况下发送K2个更多消息。

可能有几种方法可以应对这一挑战：

提供具有更多核心的云功能，类似于VM实例，因此多个任务可以在通过网络发送或接收之后组合并共享数据。
允许开发人员明确将云功能放在同一个VM实例上。提供应用程序可以开箱即用的分布式通信原语，以便云提供商可以将云功能分配给同一个VM实例。
让应用程序提供计算图，使云提供商能够共同定位云功能，以最大限度地减少通信开销（请参阅上面的“抽象挑战”）。

请注意，前两个提案可能会降低云提供商放置云功能的灵活性，从而降低数据中心利用率。可以说，它们也违背了无服务器计算的精神，迫使开发人员考虑系统管理。

4.4 Security challenges

无服务器计算重新安排了安全责任，将其中许多人从云用户转移到云提供商，而没有从根本上改变它们。但是，无服务器计算还必须解决应用程序分解多租户资源共享中固有的风险。无服务器计算重新安排了安全责任，将其中许多人从云用户转移到云提供商，而没有从根本上改变它们。但是，无服务器计算还必须解决应用程序分解多租户资源共享中固有的风险。

Scheduling randomization and physical isolation: 物理共存是云中硬件级边通道或Rowhammer [62]攻击的中心。作为这类攻击的第一步，对抗性租户需要在同一物理主机上确认与受害者的同居，而不是随机攻击陌生人。云功能的短暂性可能会限制攻击者识别同时运行的受害者的能力。随机化，对手感知调度算法[63]可能会降低共同定位攻击者和受害者的风险，使共存驻留攻击更加困难。但是，故意阻止物理共存可能与放置相冲突，以优化启动时间，资源利用或通信。

Fine-grained security contexts：云功能需要细粒度的配置，包括访问私钥，存储对象甚至本地临时资源。将要求从现有的服务器应用程序转换安全策略，并提供高度表达的安全API以便在云功能中动态使用。例如，云功能可能必须将安全权限委托给另一个云功能或云服务。使用加密保护的安全上下文的基于能力的访问控制机制可以自然地适用于这种分布式安全模型。最近的工作[64]建议在多方设置中使用信息流控制进行跨功能访问控制。如果为云功能动态创建短期密钥和证书，则会加剧提供安全原语的分布式管理的其他挑战，例如非模糊性[65]和撤销。

在系统级别，用户要求为每个功能提供更细粒度的安全隔离，至少作为一种选择。提供功能级沙盒的挑战是保持较短的启动时间，而不会以在重复的功能调用之间共享状态的方式缓存执行环境。一种可能性是本地快照实例，以便每个功能可以从干净状态开始。或者，轻量级虚拟化技术开始被无服务器提供商采用：库操作系统，包括gVisor [14]，在用户空间“填充层”中实现系统API，而unikernel和microVM，包括AWS Firecracker [15]，流客户内核并帮助最小化主机攻击面。与以秒为单位测量的VM启动时间相比，这些隔离技术将启动时间减少到几十毫秒。这些解决方案在安全性方面是否实现了与传统虚拟机的平价仍有待展示，我们期望寻找具有低启动开销的强大隔离机制成为正在进行的研究和开发的活跃领域。从积极的方面来说，无服务器计算中的提供程序管理和短期实例可以更快地修补漏洞。

对于需要防止共存驻留攻击的用户，一种解决方案是要求物理隔离。最近的硬件攻击（例如，Spectre [66]和Meltdown [67]）也使得整个核心甚至整个物理机器都能够为用户提供吸引力。云提供商可以为客户提供高级选项，以便在专用于其使用的物理主机上启动功能。

Oblivious serverless computing：云功能可以通过通信泄漏访问模式和时间信息。对于服务器应用程序，通常批量检索数据，并在本地缓存。相比之下，由于云功能是短暂的并且广泛分布在云中，因此网络传输模式可以将更敏感的信息泄露给云中的网络攻击者（例如，员工），即使有效负载是端到端加密的 - 结束。将无服务器应用程序分解为许多小功能的趋势加剧了这种安全风险。虽然主要的安全问题来自外部攻击者，但通过采用不经意的算法可以保护网络模式免受员工的影响。不幸的是，这些往往有很高的开销[68]。

4.5 Computer architecture challenges

Hardware Heterogeneity, Pricing, and Ease ofManagement：唉，主宰云的x86微处理器性能几乎没有提高。 2017年，单项计划绩效仅提升3％[69]。假设趋势继续下去，表现将不会翻倍20年。同样，每芯片的DRAM容量接近其极限; 16 Gbit DRAM今天正在销售，但构建32 Gbit DRAM芯片似乎不可行。这种缓慢变化速度的一线希望是让供应商更换旧电脑，因为它们在当前无服务器市场上几乎没有中断。

通用微处理器的性能问题不会降低对更快计算的需求。前进有两条路[70]。对于使用JavaScript或Python等高级脚本语言编写的函数，硬件 - 软件协同设计可能会导致语言特定的自定义处理器运行速度提高一到三个数量级。另一条前进道路是Domain Specific Architectures。 DSA针对特定问题域进行了定制，并为该域提供了显着的性能和效率提升，但对该域外的应用程序执行效果不佳。图形处理单元（GPU）长期以来一直用于加速图形，我们开始看到用于机器学习的DSA，例如Tensor Processing Units（TPU）。 TPU的性能优于CPU的30倍。这些示例是众多中的第一个，因为针对不同域增强了DSA的通用处理器将成为常态。

如上面4.1节所述，我们看到了无服务器计算的两条路径，以支持即将到来的硬件异构性：

无服务器可以包含多种实例类型，每个会计单位的价格不同，具体取决于所使用的硬件。
云提供商可以自动选择基于语言的加速器和DSA。这种自动化可以基于云功能中使用的软件库或语言隐式完成，例如用于CUDA代码的GPU硬件和用于TensorFlow代码的TPU硬件。或者，云提供商可以监控云功能的性能，并在下次运行时将其迁移到最合适的硬件。

对于x86的SIMD指令，无服务器计算现在在很小的方面面临异构性。 AMD和英特尔通过增加每个时钟周期执行的操作数量并添加新指令，迅速改进了x86指令集的那一部分。对于使用SIMD指令的程序，在具有512位宽SIMD指令的最新Intel Skylake微处理器上运行要比在具有128位宽SIMD指令的旧版Intel Broadwell微处理器上运行要快得多。今天，两个微处理器在AWS Lambda中以相同的价格提供，但目前无服务器计算用户无法表明他们想要更快的SIMD硬件。在我们看来，编译器应该建议哪种硬件最匹配。随着加速器在云中变得越来越流行，无服务器的云提供商将不再能够忽视异构性的困境，特别是因为存在可行的补救措施。

随着加速器在云中变得越来越流行，无服务器的云提供商将不再能够忽视异构性的困境，特别是因为存在可行的补救措施。

5. Fallacies and Pitfalls

6. Summary and Predictions

通过提供简化的编程环境，无服务器计算使云更易于使用，从而吸引更多能够并将使用它的人。无服务器计算包括FaaS和BaaS产品，标志着云编程的重要成熟。 它不再需要手动资源管理和优化，而今天的服务器计算对应用程序开发人员施加了压力，这种成熟类似于四十多年前从汇编语言转向高级语言的过程。我们预测无服务器的使用将会飙升。我们还预计，随着时间的推移，混合云本地应用程序将逐渐减少，但由于监管限制和数据治理规则，某些部署可能会持续存在。

我们预测无服务器的使用将会飙升。我们还预计，随着时间的推移，混合云本地应用程序将逐渐减少，但由于监管限制和数据治理规则，某些部署可能会持续存在。

无服务器计算的未来面临的两个挑战是提高安全性并适应可能来自专用处理器的成本 - 性能提升。在这两种情况下，无服务器计算都具有可以帮助解决这些挑战的功能。物理共存是旁道攻击的必要条件，但在无服务器计算中更难确认，并且可以轻松采取步骤随机化云功能放置。在JavaScript，Python或TensorFlow等高级语言中编写云函数的程序提高了编程抽象的水平，使其更易于创新，从而使底层硬件能够提高成本性能。

伯克利的云计算视图[2]预测，2009年云计算面临的挑战将得到解决，并且它将蓬勃发展。云业务每年增长50％，并证明云服务提供商的利润很高。

我们在本文中总结了以下关于未来十年无服务器计算的预测：

我们希望无服务器计算能够比服务器计算更安全地进行编程，这得益于高级编程抽象和云功能的细粒度隔离。
我们认为无服务器计算的成本应该高于服务器计算的成本没有根本原因，因此我们预测计费模型将不断发展，几乎任何规模运行的应用程序都不会花费更多，也许更少无服务器计算。
服务器计算的未来将是为了促进BaaS。在无服务器计算之上难以编写的应用程序（例如OLTP数据库或队列等通信原语）可能会作为来自所有云提供商的更丰富服务集的一部分提供。
虽然服务器式云计算不会消失，但随着无服务器计算克服目前的局限性，云部分的相对重要性将下降。
无服务器计算将成为云时代的默认计算范例，主要取代服务器计算，从而为客户端 - 服务器时代带来封闭。

Cloud Programming Simplifie : A Berkeley View on Serverless Computing相关推荐

Cloud Programming Simplified: A Berkeley View on Serverless Computing
云计算编程的简化:伯克利对无服务器计算的观点 Abstract 无服务器云计算几乎处理了所有的系统管理操作,使程序员更容易使用云计算.它提供了一个接口,大大简化了云计算编程,并代表了从汇编语言到高级编 ...
Cloud Programming Simplified: A Berkerley View on Serverless Computing笔记
今天读了一篇加州大学伯克利分校发表的论文 Cloud Programming Simplified: A Berkeley View on Serverless Computing,文章对server ...
无服务计算的未来和挑战: A Berkeley View on Serverless Computing
加州大学伯克利分校继 2009 年发布 <The Berkeley View on Cloud Computing>一举拨开云计算迷雾,十年后又一次发布了 <A Berkeley V ...
《A Berkeley View of systems challenges for AI》总结
一. 本文之前的工作 a berkeley view of 系列共出现过2篇,除了本文要总结的这篇,还有2009年发布的另一篇<Above the Clouds:A Berkeley View ...
【转】无服务计算（Serverless Computing）核心知识
Serverless Computing概念云原生计算基金会CNCF(Cloud Native Computing Foundation, CNCF)Serverless Whitepaper v1 ...
Serverless Computing Fass $ openwhisk快速部署、应用、实例
前一段时间接触到无服务计算,其实无服务计算在当前云计算平台中扮演很重要的作用(使用了aws lambda,发现Fass真的很好用).当时发现国内对于Fass以及Openwhisk的介绍太少了,这里把自 ...
FaaS — Serverless Computing（无服务器计算）
目录文章目录目录 Serverless Computing(无服务器计算) Serverful 与 Serverless FaaS 与 BaaS Serverless 的优势免运维极致弹性开 ...
阿里云徐立：面向容器和 Serverless Computing 的存储创新
*作者:徐立云原生的创新源泉云原生趋势下,应用容器化比例正在快速增长,Kubernetes 也已成为云原生时代新的基础设施. Forrester 预测到 2022 年,全球组织/公司在生产环境运行 ...
【论文总结】[ATC '18] SAND:A high-performance serverless computing platform
SAND:A high-performance serverless computing platform 这是一篇来自ATC18的文章.这篇文章主要,介绍了一种高性能无服务器计算平台.有关Serve ...

Cloud Programming Simplifie : A Berkeley View on Serverless Computing