Serverless的危机:前进一步,后退两步

本周推荐论文:cidrdb.org/cidr2019/pap

当前,Serverless的热度可谓如日中天,受到了各大云计算厂商和巨头的推崇和追捧,和之前的Kubernetes相比有过之而无不及,生怕错失了新一波云计算和服务变革的潮流。那么在这波潮流的后面到底是新的历史变革还是“风口上的猪”呢?加州大学伯克利分校发布了 《Serverless Computing: One Step Forward, Two Steps Back》,为Serverless泼了泼冷水,指出了Serverless的一些关键缺陷,试图在提醒追求潮流的同时回归理性,并提出我们需要重新思考我们如何设计基础架构和编程模型以激发数据丰富的云规模系统中的真正创新,并审视和承认所谓的“无服务器计算”的设计和局限性。

(推荐出自同一个实验室的它的姊妹篇:无服务计算的未来和挑战: A Berkeley View on Serverless Computing,从另一个视角看待Serverless,可以对比来看下



Serverless计算在针对自动缩放,按需付费的提供了对云进行编程或者说云原生的能力。 在本文中我们指出第一代Serverless计算中的关键缺陷——它的自动缩放能力与现代计算主流趋势并不一致:包括数据中心、分布式计算、开源技术和自定义硬件。 把这些缺陷放在一起使得当前无服务器产品并不适合云创新,对数据系统创新尤其不利。 此外针对当前无服务器架构的一些主要缺陷,提出了一系列必须满足的挑战以便可以解放云的潜力:凭借其艾字节级别的存储和数百万个核心提供给开发人员。

AWS最早提出了一个激进的新计算平台:数据容量和分布式计算能力的最大组合,一般公众可以作为一项服务进行管理。尽管有这种潜力,但我们还没有以激进的方式利用云资源。其实,今天的云主要用作标准企业数据服务的外包平台。为了实现这一目标,开发人员需要能够利用云计算能力的编程框架,从而发挥这个潜力。

新的计算平台通常促进了编程语言和环境的创新。然而十年之后,很难确定云的新编程环境。无论其因果关系,结果在实践中都清晰可见:大多数云服务都是简单的多租户,更易于管理的遗留企业数据服务克隆,如对象存储,数据库,排队系统和Web / app服务器。多租户和管理简单性是令人钦佩和理想的目标,并且一些新服务本身具有有趣的内部功能。但这充其量只是暗示了数百万核心和数十亿数据提供的潜力。最近,公共云供应商开始在无服务器计算的旗帜下提供新的编程接口,并且兴趣正在增长。无服务器计算提供了云中台的吸引人的概念,开发人员只需上传他们的代码,平台就可以根据需要以任何比例代表他们执行。开发人员无需关心配置或运行服务器,并且只需为调用代码时使用的计算资源付费

无服务器计算的概念足够模糊,允许乐观主义者对它可能意味着什么进行任何可能的广泛解释我们的目标不是对术语进行狡辩。具体而言,每个云供应商已经启动了无服务器计算基础架构,并且正在花费大量的营销预算来推广它。在本文中,我们基于供应商实际提供的无服务器计算服务来评估该领域,并根据云的潜力查看为什么他们会感到失望。

1.1“无服务器”成为FaaS

FaaS背后的想法很简单,直接来自编程教科书。传统编程基于写入功能,即从输入到输出的映射。程序包含这些功能的组合。因此,编程云的一种简单方法是允许开发人员在云中注册函数,并将这些函数组合成程序。

当今典型的FaaS产品支持多种语言(例如,Python,Java,Javascript,Go),允许程序员向云提供者注册功能,并使用户能够声明触发每个功能的事件。 FaaS基础结构监视触发事件,为函数分配运行时,执行它并持久保存结果。仅对用户调用期间使用的计算资源向用户收费。

FaaS提供本身没什么价值,因为每个功能执行都是孤立的和短暂的。除了触发和扩展功能执行的机制之外,在FaaS上构建应用程序还需要在持久存储和临时存储中进行数据管理。因此,云提供商很快就会强调无服务器不仅仅是FaaS。它是由“标准库”支持的FaaS:由供应商提供的各种多字节自动缩放服务。对于AWS,这包括S3(大对象存储),DynamoDB(键值存储),SQS(排队服务),SNS(通知服务)等。整个基础架构由AWS管理和运营;开发人员只需注册使用这些服务的FaaS代码,并接收“按需付费”账单,这些账单可根据存储和计算使用情况进行扩展和缩减。

1.2前进还是倒退

我们强调无服务器计算提供的编程模型不仅仅是弹性的,因为人类或脚本可以根据需要添加和删除资源;它是自动缩放。工作负载自动驱动资源的分配和释放。随着现代应用程序在动态性和复杂性方面的增加,动态分配VM,监视服务和响应工作负载变化的任务变得越来越繁重,需要不断的人工观察或为个别应用程序开发的定制脚本。通过提供自动缩放功能,今天的FaaS产品向云计算迈出了一大步,提供了一个实际可管理的,看似无限的计算平台。

2服务器更多?简单的案例

当前的FaaS解决方案对于独立任务的简单工作负载具有吸引力 - 无论是嵌入在Lambda函数中的并行任务,还是由专有云服务运行的作业。 涉及有状态任务的用例具有令人惊讶的高延迟:10分钟是云供应商宣传的长周转时间,即使对于注册工作流也是如此。 这些现实限制了当今FaaS的有吸引力的使用案例,阻止了超出供应商专有服务产品的新第三方程序。

3为什么今天服务器太少了

云提供三个关键功能:无限数据存储,无限的分布式计算能力,以及仅在需要时利用这些功能的能力 - 仅为您消耗的资源付费,而不是购买您在峰值时可能需要的资源。无服务器计算向前迈出了一步,并从这一愿景中退了两步。它通过自动缩放实现了即用即付,完全管理的最终用户代码执行的潜力。不幸的是,正如我们将在本节中看到的那样,当前的FaaS产品致命地限制了使用数据或分布式计算资源高效工作的能力。因此,今天的无服务器计算充其量只是一种简单而强大的方式来运行令人尴尬的并行计算或利用专有服务。在最坏的情况下,它可以被视为一种愤世嫉俗的努力,将用户锁定在这些服务中并锁定创新。

今天的FaaS产品中的限制列表非常出色。我们的运行示例AWS Lambda具有以下约束,这些约束是其他供应商的典型约束。

  1. 有限的生命周期。 15分钟后,Lambda基础架构关闭函数调用。 Lambda可以将函数的状态保持在托管VM中以支持“热启动”,但是无法确保后续调用在同一个VM上运行。因此,必须编写函数,假设状态在调用之间不可恢复。
  2. I / O瓶颈。 Lambda通过网络接口连接到云服务 - 特别是共享存储。实际上,这通常意味着跨节点或机架移动数据。使用FaaS,事情似乎比网络拓扑所暗示的更糟糕。最近的研究表明,单个Lambda函数可以实现平均538Mbps的网络带宽;来自谷歌和Azure的数字在同一个球场[27]。这比单个现代SSD慢一个数量级。更糟糕的是,AWS似乎试图在同一个VM上将同一用户的Lambda函数打包在一起,因此有限的带宽由多个函数共享。结果是,随着计算能力的增加,每功能带宽成比例地缩小。使用20个Lambda函数,平均网络带宽为28.7Mbps,比单个SSD慢2.5个数量级[27] 4
  3. 通过慢速存储进行通信。虽然Lambda函数可以启动出站网络连接,但它们本身在运行时不能以任何方式直接进行网络寻址。因此,两个Lambda函数只能通过自动调节中介服务进行通信;今天,这意味着像S3这样的存储系统比点对点网络速度慢得多且成本更高。作为必然结果,Lambda的客户端无法处理处理客户端先前请求的特定功能实例:客户端连接没有“粘性”。因此,跨客户端调用维护状态需要将状态写入缓慢存储,并在每次后续调用时将其读回。
  4. 没有专业硬件。今天的FaaS产品只允许用户提供CPU超线程和一些RAM的时间片;在AWS Lambda的情况下,一个确定另一个。没有API或机制来访问专用硬件。然而,正如Patterson和Hennessy在他们最近的图灵讲座[20]中所解释的那样,硬件专业化只会在未来几年加速。

这些约束与FaaS产品标准库中的一些重大缺陷相结合,大大限制了可行的无服务器应用程序的范围。一些推论直接跟随。

FaaS是一种数据传输架构。这可能是FaaS平台及其API的最大架构缺陷。无服务器功能在隔离的VM上运行,与数据分开。此外,无服务器功能是短暂的且不可寻址的,因此它们在内部缓存状态以服务重复请求的能力是有限的。因此,FaaS通常会“将数据传送到代码”,而不是“将代码传送到数据。”这是系统设计人员反复出现的架构反模式,数据库爱好者似乎需要指出每一代。存储器层次结构的实际情况 - 跨越各种存储层和网络延迟 - 由于延迟,带宽和成本的原因,这使得这是一个糟糕的设计决策。

FaaS Stymies分布式计算。由于无服务器功能没有网络可寻址性,因此只有通过缓慢而昂贵的存储传递数据,两个功能才能无服务地协同工作。这阻碍了基本的分布式计算。该字段基于在代理之间执行细粒度通信的协议,包括诸如领导者选举,成员资格,数据一致性和事务提交等基础知识。许多分布式和并行应用程序 - 尤其是科学计算 - 也依赖于细粒度的通信。

有人可能会说,FaaS鼓励基于全球状态的新的事件驱动的分布式编程模型。但众所周知,传递消息的进程与共享数据上的事件驱动函数之间存在二元性[17]。对于FaaS,事件处理仍然需要将全局状态的部分从慢速存储传递到无状态功能,从而产生时间和成本。同时,当前的无服务器存储产品在副本之间提供了较弱的一致性。因此,在事件驱动模式中,短暂函数之间的一致性仍然需要作为附加I / O的协议“拴在一起”,类似于经典共识。

简而言之,随着所有通信都通过存储进行转换,云中的数千个(数百万)核心无法通过当前的FaaS平台高效协同工作,而不是通过基本上不协调(令人尴尬)的并行性。

FaaS阻碍了硬件加速的软件创新。如今,许多主要的大数据用例都利用了自定义硬件。最突出的例子是在深度学习中普遍使用GPU,但是在加速器的使用方面也在不断创新。当前的FaaS产品都运行在统一且相当平凡的虚拟机平台上。这些虚拟机不仅不提供自定义处理器,而且目前的FaaS产品甚至不支持维护大型基于RAM的数据结构的主存储器数据库 - 最大的Lambda实例仅允许3GB的RAM。缺乏对这些硬件的访问 - 以及适当的定价模型 - 显着限制了FaaS产品作为软件创新平台的效用。

FaaS不鼓励开源服务创新。最流行的开源软件不能在当前无服务器产品中大规模运行。可以说这是固有的:该软件不是为无服务器执行而设计的,并且需要人工操作。但考虑到FaaS在数据处理和分布式计算方面的局限性,人们不应期望出现新的可扩展开源软件。特别是,开源数据系统 - 近年来快速增长和成熟的领域 - 将无法在当前的FaaS产品基础上进行构建。当前无服务器基础结构有意或无意地将用户锁定为使用专有提供者服务或维护自己的服务器。


3.1案例研究


为了评估这些问题的严重性,我们记录了来自大数据和分布式计算设置的三个案例研究。模特训练。我们的第一个案例研究探讨了AWS Lambda针对常见数据密集型应用程序的性能:机器学习模型培训。正如我们将看到的,它受Lambda的数据传输架构的影响很大。

使用公共亚马逊产品评论数据[2],我们配置TensorFlow来训练预测平均客户评级的神经网络。每个产品评论都使用词袋模型进行特征化,产生6,787个功能和90GB的培训数据。该模型是具有两个隐藏层的多层感知器,每个隐藏层具有10个神经元和Relu激活功能。每个Lambda都分配了最长生命周期(15分钟)和640MB RAM,并尽可能多地运行训练迭代。我们的培训计划使用AdamOptimizer,学习率为0.001,批量大小为100MB。

Lambda中的每次迭代耗时3.08秒:2.49从S3获取100MB批处理,0.59秒运行AdamOptimizer。 在该算法的294次迭代之后,Lambda函数超出其15分钟的限制。 我们训练模型超过训练数据的10次完整传递,这转换为31次连续的lambda执行,每次执行15分钟,或总延迟465分钟。 这笔费用为0.29美元。

为了比较,我们在m4.large EC2实例上训练了相同的模型,该实例具有8GB的RAM和2vCPU。 在此设置中,每次迭代都要快得多(0.14秒):从EBS卷获取数据需要0.04秒,运行优化器需要0.1秒。 相同的培训过程大约需要1300秒(不到22分钟),这意味着0.04美元的成本。 Lambda的有限资源和数据传输体系结构意味着在Lambda上运行此算法比在EC2上运行慢21倍且高出7.3倍。

通过批处理服务的低延迟预测。我们的下一个案例研究侧重于下游使用训练模型:进行实时预测。我们已经在Clipper [5]中使用低能力预测工作了一段时间。乍一看,预测服务似乎非常适合FaaS。每个功能都是独立的,可以部署多个副本以缩放使用特定模型进行的预测数量。

实际上,预测服务依赖于对GPU等专用硬件的访问,这些硬件不能通过AWS Lambda获得。抛开这个问题,我们想了解是否可以在FaaS设置中实现像Clipper这样的系统的关键性能优化。 Clipper中的一个优化是批量处理输入;在传统情况下,这提供了输入请求处理(由CPU执行)与预测的多输入矢量处理(由GPU执行)之间的流水线并行性。我们很想知道Lambda是否可以通过预测为流水线批量积累提供类似的好处。

为此,我们使用Lambda的优惠服务进行批量输入:AWS Simple Queuing Service(SQS)。我们在Lambda上编写了一个简单的应用程序,它管理由SQS完成的批处理工作,并使用Lambda函数运行一个简单的分类器。具体来说,我们的应用程序接受批量的文本文档,使用模型将文档中的每个单词分类为“脏”或不,并将文档写入存储服务,并将脏字替换为标点符号。我们在这个实验中的模型是一个简单的脏词黑名单。 SQS一次只允许批量10条消息,因此我们将所有实验限制为10条消息批次。

如果在每次调用时检索模型并将结果写回S3,则Lambda应用程序的1,000次批量调用的平均延迟为每批559ms。作为优化,我们允许将模型编译到函数本身中,并将结果放回到SQS队列中;在此实现中,平均批处理延迟为447ms。为了比较,我们使用m5.large EC2实例进行了两次实验。第一个用EC2机器取代Lambda在应用程序中的角色来接收SQS消息批次 - 这表明每批次平均超过1,000批次的延迟为13毫秒 - 比我们的“优化”Lambda实现快27倍。第二个实验使用ZeroMQ替换SQS在应用程序中的角色,并直接在EC2机器上接收消息。这种“服务器”版本的每批延迟比优化的Lambda实现快2.8ms-127x。

定价增加了对这些服务中的性能损害的侮辱。 如果我们想要将此应用程序每秒扩展到100万条消息,那么仅SQS请求率就会达到每小时1,584美元。 请注意,这不会考虑Lambda执行成本。 另一方面,EC2实例的吞吐量约为每秒3,500个请求,因此每秒100万个消息需要290个EC2实例,总成本为每小时27.84美元 - 节省了57倍的成本。 分布式计算。 Lambda禁止在函数之间直接建立网络连接,因此我们不得不尝试其他解决方案来实现分布式计算。 正如我们将看到的,可用的解决方案无法缓慢。

表1:延迟。 我们以各种方式比较“通信”1KB的延迟。 为了模拟纯函数事件驱动的通信,我们展示了在1KB参数上调用无操作Lambda函数的成本,平均超过1,000个调用。 然后,我们展示了两个显式的1KB I / O(写入+读取)从Python Lambda函数和一个EC2实例到S3和DynamoDB的成本,平均为5k次试验。 最后,我们通过测量1KB网络消息往返来显示直接消息传递的成本,使用python和运行在两个EC2实例上的ZeroMQ消息库进行测量,平均进行10k次试验。

正如前一节所讨论的,实现并发通信系统有两种经典的双模式:事件驱动的共享状态执行(自然FaaS方法),或跨分布状态的长时间运行代理的消息传递[17]。在Lambda环境中,两种设计模式共享属性,即函数只能通过共享存储(S3或DynamoDB)将数据相互传递。在事件驱动模式中,数据在函数的开头和结尾读取和写入存储。在消息传递模式中,通过写入存储并通过定期轮询从存储读取来发送消息。

我们从一个简单的问题开始:云存储是否是一种合理的通信媒介?为了评估这一点,我们测量了在Python函数之间传递1KB的“发送/接收”(写入/读取)延迟。 Lambda结果非常缓慢,如表1所示。它们有两种形式。首先,我们测量由Lambda函数调用处理的1KB对象的纯函数,事件驱动编程成本 - 这会导致I / O和函数开销,并且过于昂贵5。接下来,我们测量来自Lambda的显式I / O的成本,即来自长时间运行的函数的平均写入+读取 - 这仍然比想要的慢一个数量级。我们发现EC2的延迟几乎相同,因此开销是存储服务成本,而不是Lambda。最后,我们展示了使用Python函数通过ZeroMQ直接相互寻址的(acked)消息传递的延迟。最后的成本接近典型的机架内数据中心网络测量;甚至几年前的研究报告平均机架间测量值大约为1.26ms [8]总而言之,通过云存储进行通信并不是直接寻址网络的合理替代方案,即使是直接I / O - 也只是一个订单幅度太慢。 “纯粹的”功能性FaaS编程风格将费用加剧到过度的程度,应该不惜一切代价避免。

为了更好地理解这一点,我们以沟通代理的方式构建了一个分布式系统案例研究。如上一节所述,无论您选择哪种设计模式,状态上的分布式协议(AWS中松散一致的存储中的“全局”状态)都需要某种协议。有大量分布式协议的文献,但大多数要求至少在任何时候就系统的领导者或成员资格达成一致。为了对此进行建模,我们在Python中实现了这些协议中最简单的一种:Garcia-Molina的欺负领导者选举[7]。使用Lambda,我们的功能之间的所有通信都通过DynamoDB以黑板方式完成。每次Lambda轮询每秒四次,我们发现每轮领导选举耗时16.7秒。回想一下Lambda函数在15分钟后被杀死。因此,在(无法实现的)最佳情况下 - 当每个领导者在加入系统后立即当选时 - 系统将花费1.9%的总时间简单地用于领导者选举协议。即使您认为这是可以容忍的,请注意使用DynamoDB作为细粒度的通信介质是非常昂贵的:支持1,000个节点的集群成本至少每小时450美元6。

3.2限制可以让我们自由吗?

上面描述的限制使得今天的FaaS框架无法用于构建复杂的新后端功能。但是,对开发人员的限制并不一定是件坏事。有时,新平台以鼓励开发人员编写非常适合平台的程序的方式反映其“物理”非常重要。特别是,FaaS限制有利于操作灵活性而不是开发人员控制,我们普遍认为这一主题对于云的规模和弹性至关重要,并且主要的设计转变为传统的数据系统理念。 FaaS的一些限制是否真的对分布式编程的未来有益?有时,从有限的模型开始可确保简单的任务保持简单。作为一般设计模式,无状态代码具有许多优点:它通常易于编写和调试,并且为了缩放和容错,本质上可以简单地动态地复制和重新启动。如果我们将无服务器视为DSL和运行时用于其擅长的简单任务,其局限性有助于确保良好的软件卫生。

约束的另一个好处是它们可以带来更深层次的创新。作为一个突出的例子,FaaS功能无法进行通信可以迫使我们更深入地思考为什么以及何时应该使用来自分布式系统的协调协议,以及何时我们可以无协调地运行。今天的FaaS框架几乎没有关于跨功能的顺序执行的保证。开发人员被迫从异步任务中编写更大的程序,但没有任何保证

像顺序一致性或可序列化来推理跨任务的全局状态变异的语义。对于用于编写顺序程序或事务的开发人员而言,这些限制可能具有挑但结果可能既健康又易于管理:这种“无序”松散一致的模型是近年来可扩展的可用程序设计的一些更通用的建议的核心,包括来自我们的团队[9] ,1,23,15]。该领域最近工作的一个标志是它提供了比黑盒功能组合更丰富的编程结构;但原则上,这些想法可以在FaaS之上分层。另一个例子是,今天的FaaS框架不能保证物理硬件的局部性:开发人员无法控制函数的运行位置,或者物理地址是否保持不变。同样,这可能是一个可管理的约束:动态变换代理的虚拟寻址是预先设定云服务的对等研究中先前工作的标志[22,25]。

简单性的另一个好处是它可以促进平台开发和社区。 MapReduce有一个建设性的类比。虽然MapReduce本身并不成功,但对于开发人员来说却很简单;因此,它帮助改变了开发人员社区的思维方式,并最终将SQL和关系代数(以“数据帧”库的形式)重新注册为流行的,可扩展的接口,用于编写复杂的分析。也许今天的FaaS产品同样会导致大规模分布式编程的先前想法重新焕发活力。一个值得注意的差异是SQL和关系代数已经很好地建立起来了,而异步分布式编程对云中数据的自然终态仍然是一个研究和争论的问题。

我们相信,当前FaaS产品的许多限制也可以克服,同时保持自动缩放,同时释放数据和分布式计算的性能潜力。在下一节中,我们概述了我们认为在所有三个方面取得进展的主要挑战和机遇。

3.3早期异议

在本文中,我们专注于公共FaaS API的局限性,并认为它们令人失望地远远没有为通用的,数据丰富的编程做好准备。虽然我们的许多早期读者都同意我们提出的挑战,但我们也听到了反对意见。我们试着在这里解决最常见的问题。

“你继续使用那个词。我认为这并不意味着你的意思。“

我们在云平台工作的一些同事认为,我们对“无服务器”这一术语的看法过于狭隘:在云提供商的幕后,他们正在为自动扩展和免管理的客户构建“无服务器”解决方案。我们理解使用该术语 - 我们同样谈论Google Cloud Dataprep。也许这种混乱是“无服务器”不是一个有用的形容词的原因,可以将技术社区团结在云创新之上。简而言之,提供特定的专用自动缩放后端服务并不能解决启用通用云编程的问题。此外,提供这些“无服务器”后端产品所需的工作主要是通过老式的“一次节点”编程完成的,并且是一项传统且昂贵的工作。事实上,任何人都可以通过使用像Kubernetes7这样的编排平台,在没有“无服务器”产品的情况下在公共云中完成这种工作。我们的目标是激发对云规模编程的巨大挑战的深入讨论 - 我们认为面向公众的FaaS产品正在尝试(并且目前正在失败)提供。

“等待下一次网络公告!”

早期草稿的一些读者评论说,数据中心网络正在变得越来越快,云提供商正在将这些创新传递给客户。此外,现在传统上认为,需要通过分离计算层和数据层来实现扩展。

我们对这些观点没有任何争议,但它们并没有解决我们在调整之外提出的关键问题。数据中心网络肯定会有所改进,但不可避免地会继续在更大的内存层次结构中起到限制作用。任何合理的系统设计都需要能够在网络边界的同一侧选择性地共同定位代码和数据,无论是通过在计算附近缓存/预取数据还是将计算推向更靠近数据。今天的FaaS产品都没有以有意义的方式提供这两种功能。网络速度的提高不太可能是建筑游戏改变者;他们可以改变使用某些优化的参数,但很少证明缺少这些优化机会。同时,在逻辑设计中分离计算层和存储层不应该阻止物理部署中的共址;可以独立扩展计算和存储以实现灵活性,并根据性能需求进行配置。这是“数据独立性”等架构间接的核心 - 它们增加了灵活性而不是限制它。

在较窄的技术层面,目前的网络进展似乎并不激进。像Inifiniband这样的超低延迟网络范围有限;它们需要支持交换的互连,这自然会产生延迟。然后,范围的限制通常会翻译

需要分层路由以水平扩展,这给出了延迟的异质性。与此同时,其他技术将与网络一起改进,包括HBM和NVRAM等直连存储。

“重点是简单的经济学:无服务器是不可避免的。”有些人认为本文是对无服务器计算的负面看法,从这个角度来看,这篇论文是关于历史错误的一面。毕竟,各种行业观察者都描述了无服务器计算的经济必然性。引用一个这样的:

“我不必担心建立一个平台和服务器的概念,容量规划和所有“牦牛剃须”是我的想法...然而,这些变化并不是真正令人兴奋的部分。杀手,问题是功能的计费......对于试图建立企业的人来说,这就像天上的吗哪。当然,我有投资开发代码,但应用程序是一个可变的运营成本,然后我可以赚钱与用户一起成长的印刷机... [E] xpect看到整个世界被无服务器超越2025 [28] 。“

我们不打算在这个愿景上泼冷水。重申一下,我们认为自动缩放(因此按使用付费)是向前迈出的一大步,但令人失望地局限于可以在当今蹒跚的提供商基础设施上运行的应用程序。我们承认存在这样一个“狭窄”应用程序的巨大市场,其中许多应用程序仅仅包含数据库上的业务逻辑。通过改变经济来破坏这些应用程序将把大量支出从传统企业供应商转移到新的,更高效的基于云的供应商

但是,这项业务动议不会加速云提供的计算的巨大变化。具体而言,它不会鼓励 - 甚至可能阻止第三方和开源开发新的有状态服务,这是现代计算的核心。同时,由于创新受到阻碍,云供应商增加了其专有解决方案的市场主导地位。这种推理可能表明无服务器计算可以产生局部最小值:另一种设置,其中云的计算和存储潜力在重构低技术和通常遗留用例的噪声中丢失。

我们在此讨论的目标 - 我们希望,我们的目标受众的目标 - 是将核心技术推向竞争环境,而不是在场外投注。 为此,我们希望本文将讨论从“什么是无服务器?”或“无服务器赢得?”转移到重新思考我们如何设计基础架构和编程模型以激发数据丰富的云规模系统中的真正创新。 我们认为云计算的未来远远超过当今无服务器FaaS产品的承诺。 走向未来需要重新审视当今所谓的“无服务器计算”的设计和局限性。

4迈向未来的步伐

我们坚信,云程序员 - 无论是编写简单的应用程序还是复杂的系统 - 都需要能够以自动缩放,经济高效的方式利用云的计算能力和存储容量。实现这些目标需要一个超越FaaS的可编程框架,以动态管理资源分配,以满足用户指定的计算和数据性能目标。

在这里,我们确定了为云实现真正可编程环境所仍然存在的一些关键挑战。

流体代码和数据放置。为了获得良好的性能,基础架构应该能够并且愿意物理地共存某些代码和数据。这通常最好通过将代码发送到数据来实现,而不是将数据提取到代码的当前FaaS方法。同时,弹性要求代码和数据在逻辑上分开,以允许基础架构适应放置:有时需要复制或重新分区数据以匹配代码需求。从本质上讲,这是数据独立性的传统挑战,但是在极端和不同的规模上,具有多租户使用和及时的细粒度适应性。高级,以数据为中心的DSL(例如,SQL + UDF,MapReduce,TensorFlow)可以通过高层次地揭示数据如何通过计算来使这一点变得易于处理。语言声明越多,向基础结构提供的逻辑分离(和优化搜索空间)就越多。

异构硬件支持。云提供商可以吸引大量的工作负载,使专用硬件具有成本效益。云程序员应该能够利用这些资源。理想情况下,应用程序开发人员可以使用高级DSL指定应用程序,云提供程序会将这些应用程序编译为符合用户指定SLO的最具成本效益的硬件。或者,对于某些设计,允许开发人员通过规范将代码定位到特定硬件特征可能是有用的,以促进创新的硬件/软件协同设计。人们可以就这种共同设计是否合适,或者“硬件独立性”是否是云中最重要的问题进行哲学辩论。在任何一种情况下,识别硬件亲和力并不意味着我们提倡硬件与服务的紧密绑定;平台应根据程序员提供的或从代码中提取的逻辑性能要求规范,对区分资源的代码分配做出动态的物理决策。然后可以将这些规范用于更一般的异构性感知资源空时分复用[26]。

长时间可寻址的虚拟代理。 代码,数据和/或硬件之间的亲和力往往会随着时间的推移而重现。 如果平台支付创建亲和力的成本(例如移动数据),则应该跨多个请求收回该成本。 这激发了程序员建立软件代理的能力 - 称之为功能,参与者,服务等 - 随着时间的推移,在已知身份的云中持续存在。 这些代理应该是可寻址的,其性能可与标准网络相媲美。 但是,弹性要求规定这些代理是虚拟的,并且跨物理资源动态重新映射。 因此,我们需要虚拟替代传统操作系统结构,如“线程”和“端口”:网络中可命名的端点。 来自文献的各种想法提供了这个想法的各个方面:演员[11],元组空间[4] pub / sub [19]和DHT [22]都是例子。 选择的解决方案需要在原始网络上产生最小的开销性能。

无序编程。如上所述,分布式计算和弹性大小调整的要求需要改变编程。程序编程的顺序隐喻不会扩展到云。开发人员需要的语言能够鼓励代码在小型,精细的数据和计算单元中正常工作,这些单元可以跨时间和空间轻松移动。文献中有这些模式的例子 - 特别是在基于异步流的隐喻中,如功能反应编程[12]和网络声明语言[18]和分布式计算[1]。分布式计算中的一个特殊挑战是将这些编程隐喻与分布式数据一致性语义的推理相结合;早期的工作提供了一些答案[9,1,23,3,15],但需要做更多工作才能实现全方位服务。

灵活编程,通用IR。理想情况下,将在此领域探索各种新的编程语言和DSL。然而,对于每个语言堆栈来说,实现一整套相关优化(例如,流体代码和数据,无序构造)是繁重的。因此,为云执行开发一个通用的内部中间表示(IR)非常有用,它可以作为许多语言的编译目标。此IR必须支持来自各种语言的可插入代码,如声明性语言中的UDF或FaaS中的函数所做的那样。

服务级别目标和保证:今天,没有一个主要的FaaS产品具有用于服务级别目标的API。价格只是“大小”(RAM,核心数)和使用的运行时间的函数。为了支持实际使用,FaaS产品应该支持相应定价的前期SLO,并对错误估计给予适当的惩罚。实现可预测的SLO需要在优化中获得平滑的“成本表面” - 非线性是SLO的祸根。这加强了我们上面关于具有流体放置和无序执行的代码和数据的小颗粒的讨论。

安全问题:云编程带来了与安全相关的机遇和挑战。云管理的软件基础架构将安全责任转移给云提供商的少数受到良好激励的运营人员。这一点以及适当的客户策略规范原则上应该可以缓解由于配置错误或管理不善而导致的许多安全问题。此外,如果通过更高级别的抽象实现云编程,它将为程序分析和约束实施提供机会,从而提高安全性。但是,本文中对性能的一些期望的体系结构改进使得责任方更难以实现安全性。例如,允许代码流向共享数据存储是一件非常棘手的事情:它会加剧与多租户相关的安全管理挑战以及恶意代码在客户之间收集信号的可能性。但是在这个领域有创新的研究机会。硬件飞地等技术可以帮助保护正在运行的代码,并且在这些设置中已经开始进行数据处理(例如,[29])。同时,研究人员和开发人员不仅要考虑预防性技术,还要考虑保证审计和事后安全性分析的方法,以及能够实现更细粒度和易于使用的最终用户控制的技术超过政策。

总而言之,这些挑战似乎既有趣又可以克服。 来自云提供商的FaaS平台并非完全开源,但上面描述的系统问题可以由第三方使用容器编排等云功能在新系统中进行探索。 程序分析和调度问题可能为更正式的研究开辟了重要机会,特别是对于以数据为中心的计划。 最后,语言设计问题仍然是一个令人着迷的挑战,它将程序分析能力与程序员的生产力和设计品味联系起来。 总之,我们乐观地认为研究可以为程序员打开云的全部潜力。 无论我们将新结果称为“无服务器计算”还是其他东西,未来都是不稳定的。

编辑于 2019-09-12

文章被以下专栏收录