函数即服务的工业实践研究

一项关于函数即服务软件开发在工业实践中应用的混合方法实证研究

摘要

函数即服务（FaaS）描述了一类云计算服务，这类服务使应用开发者无需关注底层基础设施，因而属于更广泛的 “无服务器”计算模型范畴。在使用AWS Lambda等FaaS服务时，开发者提供其函数的原子性且短时运行的代码，由FaaS提供商按需执行并进行横向扩展。目前，尚无系统性研究探讨开发者如何使用无服务器技术、哪些类型的应用适合该模型，或基于FaaS的应用所依赖的架构风格与实践方式。本文呈现了一项混合方法研究的结果，结合了对开发使用FaaS的应用和系统的从业者的访谈、对灰色文献的系统性分析以及一项基于网络的调查。我们发现，成功采用FaaS需要一种不同的思维模式，即系统主要通过组合现有服务来构建，而FaaS通常充当将这些服务连接在一起的“粘合剂”。工具链的可用性和成熟度，特别是在测试和部署方面，仍然是一个主要难题。此外，我们发现当前的FaaS系统缺乏对函数复用的系统性支持，用于构建非平凡FaaS应用程序的抽象机制和编程模型也较为有限。最后，我们讨论了这些发现对FaaS提供商、软件开发者和研究人员的影响。

1. 引言

自出现以来，可编程云一直是应用部署领域快速发展的热点。包括 亚马逊网络服务、谷歌云、微软Azure和IBM云（前身为Bluemix）在内的各类提供商，在云栈的不同层级上提供服务，例如基础设施即服务(IaaS)或平台即服务(PaaS)。IaaS服务通常适用于“迁移即用”式的迁移，整个应用程序可以作为高度独立的虚拟机(VMs)或容器进行迁移，无需深度修改。然而，PaaS服务提供了更高层次的抽象，要求在应用程序的架构、构建和部署方式上做出更多调整，以换取更丰富的开发体验和更多内置功能（Sharma 等，2013）。最终，许多部署在PaaS云中的应用程序是“云原生”的，这意味着它们专为云环境甚至特定的服务组合而构建，难以在其他环境中轻松运行。

这带来了一定程度的厂商锁定，但从业者通常仍愿意接受，以换取内置的弹性与容错能力、更低的运营成本，以及无需管理自身基础设施的便利（奇托等，2015）。

近年来，“无服务器计算”1这一术语逐渐流行，用来描述云原生模型的巅峰：一个“无服务器”云应用被部署到对应用开发者完全透明的基础设施组件上。无服务器的核心承诺有时被尖锐地描述为“无运维”（NoOps），这是对知名DevOps运动（巴塞特等，2015）的文字游戏，强调至少在理论上，维护一个无服务器应用无需进行任何运维操作。

无服务器模型最突出的实现是函数即服务（FaaS）服务，例如 AWS Lambda、Azure 函数或 IBM 和谷歌的云函数。使用 FaaS 服务时，应用程序开发者提供相对原子且通常短时间运行的函数的源代码，并定义触发这些函数执行的条件，例如 HTTP 请求或系统事件。FaaS 提供商随后按需将这些函数作为独立实例执行和计费，并对其执行进行扩展。

根据需要进行横向扩展。理想情况下，使用 FaaS 的应用开发人员可受益于简单的部署、减少的运维工作以及按需付费的定价模式，而服务提供商则有机会用相对较少的资源高效地服务大量用户和函数。

毫不奇怪，FaaS的这些优点并非没有代价。基于FaaS的应用需要遵守大量技术和架构上的限制，以方便其透明化管理。例如，在撰写本文时，部署到AWS Lambda的函数无法在调用之间保留状态，必须在5分钟或更短时间完成处理，执行时间存在不可预测的偏差，并且无法使用超过单个CPU线程（Malawski 等，2017）。更重要的是，AWS Lambda和其他FaaS服务最终旨在托管用几百行程序代码实现的小型微服务。从这种无状态微服务构建大型应用，或将现有的单体应用拆分为此类微服务，仍然是一个具有挑战性的开放问题（Mazlami 等， 2017；巴塞特等，2015）。

在本文中 ，我们提出了首个针对基于 FaaS的应用程序的软件开发的系统性研究 。我们的研究探讨了以下研究问题 ：
- RQ1:当前工业实践中，基于 FaaS 的计算用于哪些类型的应用？该技术适用于哪些类型的用例？
- RQ2:构建 FaaS 应用的关键架构模式和最佳实践是什么？
- RQ3:在实践中使用无服务器和 FaaS 的主要优点和挑战是什么？

鉴于研究主题尚不成熟，我们采用探索性的混合方法实证研究设计来回答这些问题。我们首先对多元化（“灰色” 加鲁西等人（2016））文献（例如，在线博客）进行结构化综述，并对领域内的 12名实践者 进行半结构化访谈。我们采用扎根理论以及开放编码和轴心编码方法，生成一系列与研究问题相关的初步发现和假设，然后通过一项面向 182 名有效受访者 的基于网络的调查对其进行验证和完善。

我们的研究表明，函数即服务通常用于后端场景，在这些场景中，该技术常被用来处理批处理任务。构建面向用户的函数即服务应用是可行的，但需要精心设计以应对由于容器启动导致的尾部延迟较慢问题。

采用无服务器架构需要不同的思维模式，其中系统主要通过组合现有服务来构建，而函数即服务通常充当将这些服务整合在一起的“粘合剂”。

函数即服务提供了技术和业务相关优势，但对于大型应用而言，管理和预测部署成本较为困难。此外，工具链的可用性和成熟度，特别是与测试和部署相关的方面，仍然是进入该领域的障碍。最后，对函数共享的支持有限以及缺乏服务生态系统被视为一项挑战。

本文其余部分结构如下。我们在第2节中提供有关FaaS服务、云函数开发以及其他重要概念的详细信息。在第3节中，我们详细讨论研究设计，接着在第4节中广泛讨论结果和研究结果。第5节探讨了这些结果的主要影响，并为FaaS提供商、用户和研究人员提出了核心经验教训。第 6节将我们的工作置于现有研究体系的上下文中。最后，第7节对全文进行总结并得出结论。

2. 背景

本节介绍了函数即服务 (FaaS) 的主要概念和架构 。此外还介绍了选定的技术栈、提供商以及开发者工具，包括它们的特性与局限性。

2.1. 函数即服务特性

FaaS服务允许开发者提供代码片段，这些代码在被触发后会在隔离环境中执行。这种模型可以被视为对先前云计算范式的演进。早期的云计算服务（如亚马逊EC2或SoftLayer）依赖于（编排的）虚拟机，这些虚拟机连同系统容器一起提供了高度的隔离性以及架构特定但语言无关的封装。平台即服务（PaaS）服务（如Heroku）通过提供特定语言的应用运行时提高了抽象层次，这些运行时通常是长时间运行的。相比之下，FaaS服务提供了更细粒度的可扩展性以及相应的定价模式。

单个函数通常仅描述大型应用的一部分。例如，单个函数可能只实现此类接口中的一个端点，而不是包含具有RESTful接口的完整Web应用。函数执行时间有限，最多几分钟。一旦超过此阈值，执行将超时。

根据配置，失败的执行（由于超时或其他任何原因）可能会自动重试。因此，函数逻辑应以幂等方式实现（Hummer 等，2013）。函数可以接收输入数据，这些数据可能为函数执行所必需或影响函数执行，并生成输出数据。此外，函数执行还可能产生其他数据，如日志或执行指标。

函数执行由事件触发，而这些事件的性质可能多种多样。例如，客户端请求、由（外部）系统生成的事件、数据流，甚至描述上述情况组合的复杂规则，都可以被配置为触发函数。具体可用触发器则取决于具体的函数即服务（FaaS）平台。

FaaS 提供商负责根据传入事件的数量横向扩展函数执行。也就是说，函数开发者无法了解其代码的实际配置情况，但可以假设系统会提供足够的资源来应对服务所经历的任何工作负载。这些资源通常采用按需付费模式进行计费，例如根据函数执行次数、函数执行时间或输入/输出操作计费。也就是说，成本通常直接取决于使用量，未被调用的空闲函数不会产生或仅产生极少的费用。

函数被视为无状态的。在执行结束后，内存中的状态不能也不应在下一次函数执行期间被假定为可用。函数可以用各种编程语言编写，但具体支持哪些语言取决于特定的 FaaS 提供商。大多数提供商至少支持基本的 JavaScript（Node.js）、Python 和 Java 运行时，但要求函数封装额外的第三方库。

2.2. 常见的函数即服务 FaaS系统架构

图 1 展示了一个具有前述特性的函数即服务系统示例架构。该架构 loosely 基于公开可用的 Apache OpenWhisk 函数即服务系统。

在设计时，函数开发者通过与函数控制器交互来创建、更新或删除函数。作为此过程的一部分，他们提供函数源代码，设置事件触发器，并可能定义函数执行规则。函数源代码存储在函数数据存储中，触发器和规则存储在用户/租户数据存储中。

在运行时，传入事件由事件控制器处理。它根据用户/租户数据存储中的触发器和规则确定要执行的函数。该控制器还确保事件经过身份验证并已授权进行处理。事件控制器根据当前系统负载确定应由哪个容器运行时来执行该函数。然后将执行任务排队，以确保即使在高系统负载或发生（部分）系统故障的情况下也能执行。接下来，（指定的）容器运行时从队列中获取执行任务。它要么启动一个新的函数容器，并将所需的函数源代码从函数数据存储注入其中，要么复用一个现有的函数容器进行执行。重要的是，服务用户或开发者无法控制函数即服务服务是分配现有容器还是配置新容器。函数在选定的容器中执行，执行结果被持久化到执行数据存储中，之后可通过事件控制器返回给客户端。容器运行时可能会使执行超时的任务终止，并最终销毁空闲函数容器。

容器运行时可能会复用现有容器，这导致函数并非完全有状态：被复用的容器可能允许访问之前执行期间在磁盘上设置的状态，但无法保证未来的调用实际能够访问该状态。容器复用也会影响函数的响应时间。

启动新容器并注入函数代码需要大量时间（长达数秒，具体取决于所使用的编程语言），这导致函数出现较高的尾部延迟（Baldini 等，2017）。

2.3. 示例函数

在清单1中提供了一个用于AWS Lambda的示例函数，该函数从 S3数据存储中获取图像并运行目标检测算法。该示例使用Python编程语言编写。函数通常需要实现一个通用接口，接收触发事件和上下文作为输入，并通常生成一个可JSON序列化的对象作为输出。函数实现通常较为简洁，如所提供的示例所示。

Listing 1:. Python 中的 AWS Lambda 函数示例。

2.4. 函数即服务提供商

目前所有主要云提供商都提供了函数即服务实现。FaaS服务包括 AWS Lambda、IBM Cloud Functions（基于开源项目Apache OpenWhisk）、Microsoft Azure Functions和Google Cloud Functions。通常，这些FaaS服务提供与其他云服务的集成，例如 API网关，用于监控、控制和计费函数使用，以及身份验证和授权服务，或可触发函数执行的应用服务、分析服务或开发系统。此外，还存在一些更专业的FaaS服务，如IronFunctions或Webtask.io。

2.5. 函数即服务开发者工具链

大多数 FaaS 提供商提供命令行接口（CLI）、软件开发工具包（ SDK）以及其他资源，以促进云函数的设计、实现、测试和部署。例如，亚马逊网络服务除了提供多种编程语言的 SDK 外，还提供参考函数、教程、网络研讨会、应用程序仓库3、API 参考以及本地测试框架。此外，一些提供商提供编排工具，如 IBM Composer、AWS Step Functions 和 Fission 工作流，帮助开发者通过函数构建大型应用或执行复杂的工作流。这些工具允许定义函数的序列和/或并行执行，并提供处理执行失败的策略。最后，许多 FaaS 提供商提供指标收集、追踪和调试工具，尽管有时需额外付费。示例包括 AWS X‐Ray 和 Google Stackdriver。

除了提供商提供的工具之外，还涌现了大量由第三方创建的工具。4 其中最重要的是一些函数即服务部署工具，例如 Serverless 框架，它抽象了函数即服务产品中与提供商相关的细节，从而能够构建和部署与提供商无关的函数。

3. 研究设计

我们基于 TAME 项目（巴斯利和罗姆巴赫，1988年）定义的模板来表述本研究的目标。本研究的目的是描述 FaaS 的使用。这种描述有助于理解，并指导从业者和研究人员在 FaaS 服务、相关工具以及相关软件工程流程的发展。本研究揭示了使用 FaaS 的常见实践、优点、缺点、挑战和机遇。本文呈现的视角来自工业界的从业者，他们在工作中开发使用 FaaS 服务的系统或应用程序。我们的关注重点是云服务提供商提供的按需使用的 FaaS 系统，以及更广泛意义上的无服务器计算。鉴于本研究主题和研究问题的探索性质，我们采用了混合方法结合定性与探索性要素和结构化的定量调查的研究方案。这遵循了布拉特霍尔和约根森（2002年）的建议，以及软件工程领域其他可比研究中的既定实践（舍曼等人，2018年；辛格等人，2014年；奇托等，2015）。

3.1. 概述

我们的研究基于三个主要数据来源：半结构化实践者访谈、多语种 （“灰色”）文献的系统性综述（例如博客和网络文章），以及一项基于网页的定量调查。采用扎根理论的方法，我们通过多轮开放编码和轴心编码，并结合对调查数据的评估。本研究方法的基本结构如图2所示。

我们的研究分为三个阶段进行。在第一阶段的探索性研究中，我们开展了访谈并分析了灰色文献。在第二阶段，我们通过在线调查对第一阶段的定性结果进行验证与量化。在第三也是最后阶段，我们对前两个阶段的结果进行了完善，并构建了关于工业界无服务器与函数即服务应用的最终理论，这是本研究的主要成果。

3.2. 半结构化访谈

与从业者的访谈是一种常见的研究方法，通常用于新兴领域，在这些领域中，仅通过同行评审文献的分析尚不足以形成稳定的科学理论来提出科学假设。我们访谈的目的是收集并整合无服务器计算和函数即服务的早期采用者所获得的、往往分散的经验教训、成功因素和最佳实践知识。

参与者选择

Given these goals, our primary 入选标准 for interview partners was 真实场景下的 生产环境经验至少使用一种FaaS技术（例如AWS Lambda、Azure Functions等）。

鉴于FaaS虽然备受关注，但仍属于小众话题，我们采用了一种机会主义的多管齐下方法来招募合适的访谈对象。首先，我们通过个人关系网寻找受访者。其次，我们有选择地联系了亚马逊网络服务和Azure的 FaaS参考客户名单上的企业，并请求安排可接受访谈的开发人员。第三，我们主动联系那些在网上公开表达其使用FaaS经验的个人（例如通过博客或Reddit讨论帖），并邀请他们参与访谈。通过这一招募策略，我们从最初联系的15人中成功获得了12位访谈对象，我们将其称为I1至I12。

表1总结了所有受访者的相关信息，包括我们如何与他们取得联系（个人关系网、AWS和Azure的FaaS参考客户名单、以及通过网页渠道）、他们所使用的云服务提供商、他们在与FaaS结合使用时采用的编程语言、其所在公司的规模（中小企业或大型企业，其中中小企业类别也包括初创企业）、地理位置分布，以及他们报告的在云技术方面的经验水平。

我们未单独列出受访者在FaaS方面的具体经验，因为该技术尚处于发展初期，即使是“经验丰富”的从业者实际使用该技术的时间通常也不超过一到两年。

我们的受访者群体涵盖了三大洲、所有主要的云服务提供商，以及初创企业、中型公司和大型企业。此外，我们采访的参与者使用了多种编程语言。在云服务提供商方面，受访者偏向于亚马逊网络服务（ AWS）和微软Azure，这并不令人意外，因为这两家提供商在我们研究期间也是函数即服务（FaaS）市场的领导者。最后，我们的大多数受访者是FaaS的最终用户，但我们还采访了两位正在自行开发FaaS解决方案的开发者（I1和I3），以及一位知名的开源工具包无服务器框架（ Serverless Framework）的主要贡献者（I6）。

研究方案

我们采用半结构化方法进行所有访谈。我们制定了一份粗粒度的访谈指南（另见本文附录）。具体而言，我们提出的问题涉及受访者过去使用FaaS的项目、他们选择使用该技术的原因、如何架构无服务器解决方案、他们认为该技术的优缺点，以及他们对FaaS未来发展的看法。然而，我们并未以相同的顺序和深度向每位受访者提问，而是根据对话的流程灵活调整。所有访谈均通过Skype或谷歌环聊远程进行，语言为英语。所有访谈均由第一、第二和第三作者共同完成（大多数访谈由多位作者共同参与）。每次访谈持续30至60分钟，并在获得受访者许可的情况下进行录音，以便于转录和后续分析。

分析

作为分析的第一步，第一、第三和第四作者手动为每次访谈制作了逐字转录文本。然后，第一和第二作者独立使用开放编码方法从所有转录文本中生成分层编码体系。随后，通过分析多源文献（见下文）得到的代码进一步丰富了这些初始编码体系。接着进入另一步分析，第一和第二作者共同讨论并解决编码中的差异，并一起进行轴心编码。该步骤形成了关于函数即服务在实践中使用的初步理论，随后与其他作者进行了讨论。我们还利用轴心编码的结果来设计基于网络的调查的问题。

3.3. 多源文献调查

正如加鲁西等人（2016）以及Barik 等人 (2015) 所指出的，软件工程领域中许多重要的讨论并非通过同行评审的科学论文进行，而是通过更非正式的出版物展开，例如面向实践者的书籍、博客、新闻稿和白皮书。尽管这些来源在讨论中至关重要，并且在实践中往往具有高度影响力，但需要以一定的怀疑态度对待它们，因为它们通常缺乏坚实的实证和方法论基础。在我们的研究中，我们选择将这类“灰色文献”视为另一种定性信息来源，类似于半结构化访谈。这反映出一个事实：单个灰色文献条目可能存在偏见或不可靠（就像任何单独一次访谈本身不一定能提供可靠的科学研究结果一样），但当它们被汇总起来时，仍然能够准确反映实践者群体对我们研究主题的看法。

顺便提一下，我们的研究也揭示了使用灰色文献作为学术研究基础的危险之一：文章A42（发表在博客网站Medium 5上的一篇博文）已在本文提交前不久被Medium删除，目前无法访问。这表明有必要将网页上现有的知识整合到归档的科学出版物中。

文章选择

我们特别关注 Hackernews 6新闻门户评论线程中的文章、博客和讨论。我们使用了 Hackernews 搜索引擎 Algolia 7，执行了“ serverless”、“aws lambda”、“azure functions”和“ openwhisk”等搜索词来发现相关文章。这些搜索词是通过迭代探索的方式生成的。最初，我们尝试了主要研究主题的不同变体（如“ serverless”、“FaaS”、“cloud functions”），但发现“FaaS”这一术语尚未足够普及，难以获得有意义的结果，而“cloud functions”又过于宽泛（许多结果为误报，涉及云的某些任意功能）。由于仅搜索 “serverless”会导致数据集偏向于几乎 exclusively 讨论 AWS Lambda，因此我们增加了“aws lambda”、“azure functions”和 “openwhisk”作为搜索词，以获得更广泛的覆盖范围。为了控制研究规模，我们聚焦于在访谈中被最突出讨论的服务（Lambda、Azure、 OpenWhisk），并决定跳过市场上存在的众多替代方案（例如 Google Functions、OpenFaaS 等）。

鉴于大量博客等资料涉及我们的研究主题，进行全面的调查被认为 是不可行的。因此，在开始收集文章之前，我们设定了收集50篇相关文章的目标。具体而言，我们决定首先为通用搜索词“serverless”选择 20个结果，并为其他每个搜索词各补充10个结果，以丰富数据集。我们 将所有搜索结果按受欢迎程度排序（基于Hackernews平台的投票）， 并按受欢迎程度顺序逐一检查每篇文章：（1）是否符合我们的纳入/排除标准（见下文），以及（2）是否已包含在数据集中。对于每个搜索词， 当我们达到预先设定的结果数量时即停止搜索。搜索分别于2017年9月 9日（serverless）和2017年10月23日（其他搜索词）执行。

我们的纳入/排除标准如下：我们接受描述参考架构、案例研究或经验报告的文章，但拒绝工具公告或纯营销性质的交流内容。如果某文章宣传了特定工具，但该工具本身是构建在函数即服务之上的（而不是其本身就是函数即服务服务），并且文章讨论了该工具如何利用函数即服务，我们则予以接受。对于每篇文章，我们还浏览了Hackernews的评论线程，如果评论中提出了与主题相关的额外重要观点，则将其纳入我们的文章分析（见下文）。我们将整个数据集称为文章A1到A50。包含链接的完整文章列表见附录。

图3展示了这些文章的发布日期（如果文章中指明了发布日期）以及它们主要讨论的云服务提供商。我们数据集中的最早文章发表于 2015年5月，最新的文章发表于2017年10月。大多数文章发表于2016年 和2017年。此外，很明显，我们数据集中的大部分文章讨论的是AWS Lambda。其他云提供商（例如微软Azure和IBM的Open Whisk）主要是在我们明确搜索它们时出现的，即通过搜索词 openwhisk和azure functions。有两篇文章讨论了谷歌云平台和开源的函数即服务实现方案。这组文章中有七篇是通用的，未讨论特定提供商。

分析

在对访谈记录进行开放式编码后，第一作者阅读了数据集中的所有文章，并根据文章中出现的新代码更新了之前的代码层级结构。也就是说，将文章文本视为另一种定性证据来源，对其进行编码，并与通过访谈收集的观点进行整合。除了文章本身外，我们还阅读了 Hackernews上与这些文章相关的评论部分。我们将这些评论与文章本身同等对待。如果从文章评论的讨论中出现了新的代码，我们会将其纳入代码层级结构中。然而，我们排除了以下两类评论：（1）被踩的评论 （在Hackernews上总评分呈负值）；（2）超出范围的评论（即讨论的内容与本研究主题无直接关联）。

与现有指南的关系

Garousi 等人 (2018) 提出了进行多源文献调查的宝贵指南。我们的研究是在这些指南的制定过程中并行开展的，因此我们并未完全遵循这些指南。然而，我们认为两者在目标和宗旨上基本一致。

我们的设计与这些指南的主要区别在于如何构建候选文章库。Garousi 等人建议使用通用搜索引擎（例如谷歌）并通过滚雪球法扩展文章库。而我们遵循 Barik 等人 (2015) 较早的建议，查询了一个更为具体的数据库（即 Hackernews），并且未采用滚雪球法。我们认为，与 Garousi 等人提出的方法相比，我们的方法既有优点也有缺点。具体而言，我们的方法更有可能遗漏相关文章。然而，该方法可能更容易复现，并且 Hackernews 通过社区评分提供了合理的文章质量指标。此外，使用 Hackernews 的另一个优点是，其文章通常附带的大量评论线程，为研究提供了除文章本身之外的另一有趣数据来源。

3.4. 网页调查

调查的主要目的是在更大范围的从业者样本中验证我们的定性研究结果。我们使用调查工具Typeform8 发布了一份匿名的基于网络的调查，共包含7个类别总计40个问题。附录中提供了部分内容，原始问卷表单可参见配套的开放研究数据存储库（Leitner 等 (2018)）。

调查传播

由于我们无法获取可发送调查的云开发者基线人口统计数据，因此采用了便利抽样方法，并通过多种不同渠道分发了调查。该调查于 2018年1月11日至2月13日公开进行，共收到182份回复，平均每天5.52 份。受访者完成调查平均耗时11分42秒，完成率为33.8%。鉴于我们采用的是便利抽样策略，无法提供调查回复率的估算值。

所有响应均标记了一个 来源属性 ，以区分调查传播 渠道 并 防止 单一 渠道的 结果 占主导 地位 。 大多数 响应 来自 一个 主题相关 的开源 项目。

然而，53.8%的受访者表示其在云计算技术方面的经验少于3年。亚马逊网络服务是受访 人群中使用最广泛的云服务提供商。

其中最后一位作者参与的9 （49.4% 的响应）、社交媒体上的广告（ 15.9% 的响应）以及德国知名 IT 新闻网站 heise.de1 0 新闻简报中的提及 （15.3% 的响应）。其余 19.4% 的响应来自作者的个人联系或其他来源。

参与者

我们的调查吸引了来自各类信息技术专业人士的回复。大多数受访者表示他们担任软件开发人员或架构师角色。此外，我们还收到了来自产品负责人、IT经理、站点可靠性工程师、DevOps工程师、研究人员以及高管的回复。

如图4所示，大多数受访者是有经验的IT专业人员（54.9%的受访者 报告拥有超过10年的专业经验），但大多数受访者（53.8%）在云计算 技术方面的经验并不丰富。这可能是因为该领域总体上还比较新。我们的调查受访者中，大多数人报告过去曾使用过亚马逊网络服务（86.3%）。

然而，微软Azure、Digital Ocean、谷歌云和Heroku也被广泛使用 （分别有30.8%、28%、26.7%和25.8%的受访者使用）。

调查问题

该调查包含七个问题组，共40个混合类型的问题，包括选择题、数值范围选项、李克特量表、布尔型是非问题和开放式文本问题。

除了人口统计信息（5个问题）外，我们还提出了与术语（1个问题）、应用架构（14个问题）、函数即服务（FaaS）开发实践与模式（10个问题）相关的问题，以及函数即服务思维模式 （5个问题），优点和挑战在使用函数即服务时 （3个问题），以及函数即服务的未来 （2个问题）。

3.5. 局限性与有效性威胁对有效性

尽管我们已将研究设计为一项基于扎根理论这一坚实理论框架的混合方法研究，但我们的研究设计仍存在一些局限性。

外部效度

在外部效度方面，问题在于我们的访谈参与者在多大程度上能够代表无服务器和函数即服务（FaaS）开发者，或总体上的云开发者。这一威胁由于53%的调查受访者表示他们对云计算技术经验不足而被放大（参见第4节）。我们通过将多源文献作为第二个定性数据源，并通过调查验证我们的发现，来缓解这一威胁。然而，本研究中的三个数据源都可能存在偏向于对FaaS持积极态度的开发人员的自我选择偏差。也就是说，对FaaS持怀疑态度或不感兴趣的开发者不太可能撰写相关博客、同意接受访谈或填写网络调查。但鉴于我们的研究目标是识别实践方法，而非确定FaaS使用的广泛程度，我们认为这种偏差的影响较小。此外，本研究聚焦于AWS Lambda、Azure 函数和IBM OpenWhisk这三种函数即服务技术。尽管在研究期间这些似乎是广泛使用的提供商，但我们的结果在多大程度上可推广到其他FaaS提供商尚不明确，特别是我们实际上已观察到不同提供商之间存在显著差异。

内部效度

在内部效度方面，我们的访谈提纲中问题和主题的预先选择可能对受访者产生了偏倚。因此，我们可能遗漏了一些有意义的编码，因为在访谈过程中未被讨论。我们的多源文献分析再次作为应对这一威胁的安全措施，因为我们预期任何主要的遗漏讨论内容都会在该分析过程中显现出来。然而，实际情况并非如此。因此，我们认为完全遗漏重要方面的风险较低。本研究内部效度的另一个威胁在于，我们必须依赖受访者、调查受访者以及文章作者如实报告其对函数即服务（ FaaS）的使用情况，也就是说，我们所报告的是参与者所述的内容，但无法了解他们实际的行为。这一威胁源于我们所采用的研究方法本身。

4. 结果

我们现在根据作为开放研究数据发布的原始结果（莱特纳等人， 2018）来讨论本研究的主要成果。正如当前Web开发趋势中常见的那样，我们发现围绕无服务器的概念和术语尚不明确。特别是“无服务器”这一名称本身就容易引起混淆，因为任何无服务器应用当然都运行在服务器上——只不过对应用开发者而言这些服务器是不可见的，A39 中也提到了这一点。

“无服务器 计算’ 并不 真正 意味 着 没有 服务器。无服务器 意味 着 没 有 需要 你 担心 的 服务器。”Scott Hanselman， 引自 在 A39 。

“无服务器”这一相对宽泛定义的一个后果是，该术语不仅包括函数即服务，还涵盖了各种其他类型的托管云服务，其中许多服务的出现时间远早于函数即服务（包括如DynamoDB（德坎迪亚等人，2007年） 等托管数据库技术）。事实上，许多早期的云计算定义都采用了相同的 “服务器”原则将“按需使用”视为云的定义特征（埃尔等人，2013年）。根据我们的一些受访者（例如，I1）的观点，FaaS 理应被理解为“计算领域的无服务器化”，而“存储领域的无服务器化”自云计算早期便已存在。

这种宽泛定义的一个问题是，它与平台即服务（PaaS）的界限并不清晰。事实上，少数受访者实际上认为Heroku或谷歌App Engine等 PaaS服务是无服务器的早期版本。然而，我们的调查结果表明，大多数受访者（58%）仍然在很大程度上将函数即服务（FaaS）和无服务器这两个术语等同起来（见图5）。

在本文的其余部分，我们将使用“无服务器”一词来表示更通用的开发模型，而FaaS则特指诸如AWS Lambda之类的云服务（但不包括 DynamoDB或Appengine等）。此外，我们使用“Serverless框架” 来指代同名的流行开源工具包。

4.1. 心智模型

在我们的研究中，我们发现成功采用无服务器技术的开发者对其系统或应用程序的思维模式与传统基于Web的应用程序开发者不同。在传统项目中，开发者通常重视“控制”其应用程序中的所有组件，并且只有在有明显优势或具体需求时才会重用现有功能（例如通过外部API）。而无服务器开发者则从根本上将其应用程序视为由小型、独立组件组合而成，其中只有一部分是由他们自己（或其团队，甚至公司）构建的。

使用外部组件成为默认做法，无服务器开发者从一开始就假设他们的大部分开发工作将用于集成现有服务，而非编写“新”代码。因此，无服务器应用程序本质上比单体应用更倾向于微服务（巴拉莱等人，2016年）。I6 甚至将无服务器称为“强化版的微服务”，即把微服务的理念推向极致。在许多方面，无服务器可被视为面向服务的架构（SOA）概念的复兴，例如服务组合（莱莫斯等人，2015年）。

此外，由于无服务器应用与云提供商生态系统中的其他服务紧密耦合，导致紧密耦合和显著的供应商锁定不可避免。在我们的调查中，三分之一的受访者认为供应商锁定在使用函数即服务时是一个重大挑战，使其成为第三大提及最多的挑战（另见第4.5节）。

“亚马逊网络服务 API 网关、 S3、 Kinesis、 SNS、 DynamoDB、 Step Functions，或其Azure和谷歌云平台中的对应服务——均在任何无服务器解决方案中发挥作用” A9 。

在我们的访谈中，一个常见的主题是：将无服务器应用程序称为 “应用程序”甚至具有误导性，鉴于其本质上存在根本差异。

“ 我认为 这个 术语 ‘应用’ 现在 很多时候 已经 不 太 适用了 （⋯⋯） 真的 很难 说清楚 ， 比如 ， 到底什么是 是 的”

应用程序不再[以及什么是部分的云或基础设施]。” I6.

我们的调查证实，使用函数即服务（FaaS）构建无服务器应用需要 与使用更传统的云计算技术（如基础设施即服务或Docker）不同的思维模式（图6）。76%的受访者同意或强烈同意这种观点，即需要不同的思维模式或思维方式才能成功构建FaaS应用。没有受访者强烈反对这一观点。

我们进一步收集了受访者通常与FaaS结合使用的其他类型（无服务器或其他）云服务的数据（图7）。不出所料，托管数据库服务（77%） 以及API网关（69%）是最常与FaaS结合使用的服务。特别是，在构建面向最终用户的纯无服务器应用程序时，使用API网关实际上已成为一项技术上的必要条件。值得注意的是，52%的受访者采用混合模型将 FaaS与IaaS结合使用，但仅有16%的受访者将其与PaaS服务（如 Heroku或CloudFoundry）结合使用。

理论上，这种以组成为核心的思维模式将能够实现函数的高度复用。然而在实践中，根据我们研究时的情况，无服务器应用主要由云提供商提供的服务、知名的外部API以及自行编写的函数组合而成。尽管受访对象认为用户间函数的对等共享这一概念颇具吸引力，但当时尚未成为现实。一些提供商维护了函数市场（例如亚马逊无服务器应用程序仓库），但截至目前，从这些市场中系统化地复用现有函数并未成为普遍做法。

“（⋯⋯） 在各种 函数 之间 共享 代码 的 想法 是 一个有吸引力的 想法。 ” I10’。

此外，受访者还表示，无服务器的不同心智模型对新进入者来说也是一个挑战，可能导致陡峭的学习曲线。

“人们 对 他们 花了 多年 时间 学习 的 东西 非常 习惯， 而 这 是不同 的。” I3.

有趣的是，这在我们的调查中并未得到证实。56%的受访者认为函数即服务背后的心理模型并不难理解（图8）。

我们推测，导致这一令人意外结果的原因之一可能是某些现有的开发实践为开发者很好地培养了采用无
服务器思维的能力。事实上，我们的调查证实，在函数式编程（70%）以及在可扩展的不可变基础设施上进行编程的经验（Cito等人（2015年），60%）被认为是在深入使用函数即服务时的重要优势（图9）。

然而，鉴于一些开发者在适应无服务器思维模式方面仍然存在困难， A20推测称，聘用经验不足的开发者有时可能反而是有益的，因为这些新手可能更容易适应函数即服务的思维模式。

“使用无服务器技术时，聘用经验较少的开发人员可能比聘用经验丰富的开发者效果更好”Paul Johnston，引用于 A20。

我们的调查受访者在一定程度上同意这一观点，尽管该观点并非没有争议（图8）——51%的受访者表示同意或强烈同意这一观点，而20%的受访者表示不同意或强烈不同意。

总结：构建无服务器和函数即服务应用程序需要一种不同的思维模式，强调“连接”微服务。目前，大多数服务要么是自行编写的，要么由云基础设施提供。采用这种不同的思维模式可能存在挑战，但具备函数式编程和不可变基础设施范式的经验会有所帮助。

4.2. 无服务器应用的类型

在我们的访谈中，出现了两个用于分类FaaS应用程序的重要维度：一是应用程序是否属于面向最终用户的请求周期（例如，被调用来响应用户请求的REST服务），或是后端应用（例如，用于整合服务器日志的函数）；二是应用程序是否完全由无服务器组件构建（“纯无服务器”），或与虚拟机、Docker容器等传统云计算技术结合使用（“混合无服务器”）。我们将其称为前者指无服务器的用例类型（面向用户或后端服务），后者指应用程序的纯度（纯的或混合的）。

如图 10所示，两种应用类型在我们的调查受访者中均较为常见。调查 40%的受访者实际上在过去已构建过这两种类型的 FaaS应用 类型 。

无服务器用例类型。尽管调查表明许多从业者实际上在构建面向用户的无服务器应用，但我们的许多受访者对这一特定用例持怀疑态度。一个经常被提及的担忧是，函数的响应时间和延迟（当提供商启动新的容器实例时，尾部延迟可达数秒，Plauth等人（2017年））不适合直接用于面向最终用户的请求周期。这些受访者认为，函数即服务的主要用例应集中在后端应用上，例如图像转换、日志或遥测数据处理、调度和执行备份、发送通知邮件等类似任务。

“它不在请求周期内直接体现我们对 Lambda的使用 ，而是更多涉及运营操作，同样包括物流、业务信息和业务数据。” I5.

另一个常见的后端使用场景是使用FaaS编写小型“胶水代码”函数，以连接其他服务或应用程序，例如从S3获取一个文件，对其进行小规模转换，然后将其转发到大数据服务进行进一步处理。可以说这正是 FaaS的真正优势所在——作为粘合剂，使开发者能够整合多种现有的托管或自研云服务。这类应用通常不会持续运行，而是以批处理或事件驱动的方式运行，因此FaaS非常适合作为实现方式。

“Lambda如何融入基础设施的自动化和管理，以及这将如何改变我们构建基础设施的方式，还有我们实际上如何以软件的形式获得这种基础设施，这对我来说一直是一件非常重要的事情。” I6.

这在我们的调查中得到了证实（图11 11 ）。大多数后端函数即服务使用场景是用于处理应用程序数据（76%）或运行定时任务（64%）。约三分之一的受访者使用函数即服务来处理监控或遥测数据。

如果我们的受访者在请求周期中使用函数即服务函数，它们通常被用作 REST API的后端实现。

在我们的研究中，出现了两种使用函数即服务（FaaS）实现REST API或服务的架构风格：一种是每个服务或REST资源使用一个函数，另一种是每种HTTP操作使用一个函数。前一种风格导致函数显著更大，需要在内部进行大量的分发处理；而后一种风格则允许使用相当小且高度细粒度的函数。当然，这也意味着在后一种风格中，需要管理的函数数量可能会急剧增加。

在我们的调查中，每个 REST 方法使用一个函数即服务（FaaS）函数被报告为最常见的架构风格（图12）。这可能是因为这种风格最符合函数即服务将微小、独立的函数作为核心范式的理念。有趣的是，15% 的调查受访者仅使用一个函数来实现整个服务或端点，这种架构风格既未出现在我们的访谈中，也未在我们对灰色文献的分析中出现。

我们的文献研究中有一篇文章描述了一种将函数即服务（FaaS）用于面向用户应用程序的有趣中间方法。他们使用 FaaS 函数生成静态 HTML，然后可通过内容分发网络（CDN）进行交付。

“将无服务器API与静态文件托管相结合，用于网站资源，例如HTML、 JavaScript和CSS，意味着我们可以构建完整的无服务器Web应用。” A49。

总体而言，我们观察到具有以下某些特性的用例往往特别适合函数即服务：
- 主要是空闲的应用程序 。函数即服务的严格按使用付费模式为这类应用程序提供了极具吸引力的成本方案。
- 需要应对具有严格可扩展性和弹性要求的突发性工作负载的应用程序 ，特别是那些即使在遭遇间歇性Slashdot效应（即负载突然且不可预测地成倍增加的短暂时期）时仍需持续提供一致服务质量的应用程序。
- 应用程序是由数据或事件流驱动的 。我们的访谈 表明 ，许多 受访者 认为 ，例如 ，物联网（IoT）场景非常适合作为函数即服务 的应用场景 。
- 早期应用原型设计，其中“以最短时间使其运行”是首要关注点。

相反，以下特性描述了某些使用场景，对于这些场景， FaaS 可能不是合适的选择。其中许多特性与当前 FaaS平台的固有局限性和限制紧密相关。
- 本质上具有强有状态特征的应用程序，例如数据库系统。
- 包含长时间运行任务的应用程序。
- 具有高 性能或 实时性要求的应用程序，其中由于虚拟化以及更重要的是 Docker 启动 延迟 带来的性能影响无法被容忍。
- 应用程序 在 数据 局 部 性 方 面 有 需 求， 即 需 要 将 数 据 存 储 到文件系统。

在这些总体限制下，一个有趣的特例是并行与高性能计算。一方面， FaaS的高延迟对这类性能关键型系统来说是一个问题。另一方面， FaaS使开发者能够基本上使用无限核心进行分布式计算，这使得该抽象对这类应用具有强大吸引力。这一点在A2中也已被观察到。

“使用Lambda进行并行处理就像根据数据集的实时增长情况，执行所需数量的函数来全面覆盖其深度和广度一样简单。这就好比拥有一个具备几乎无限核心的中央处理器。” A2.

基于函数即服务的初始科学计算框架已开始获得关注。一个例子是 PyWren框架（乔纳斯等人，2017年），它在各种FaaS提供商（最重要的是AWS Lambda）之上提供了一个并行计算框架。

纯度。第二个重要区别在于纯无服务器与混合无服务器之间的差异：在纯无服务器中，应用程序的所有部分要么是外部托管服务（如 S3 或 DynamoDB），要么基于函数即服务实现；而在混合无服务器中，这种情况仅适用于应用程序的部分组件。I2 实际上成功构建了一家初创公司，而完全无需管理服务器：整个应用是一个纯无服务器应用，且所有开发工具（例如 CI、缺陷跟踪器）均为外部托管的应用程序。纯无服务器应用的一个挑战是，由于缺乏有状态组件来保存用户认证会话，身份验证变得更加困难。这一问题也已被阿德兹奇和查特利（2017年）观察到。

在我们的访谈研究中，大多数参与者选择了混合模型。对于面向用户的应用尤其如此，这类应用通常使用有状态的、面向最终用户的入口组件（例如，nginx Docker容器）以及一个或多个使用FaaS构建的无状态请求处理器。然而，其他人选择仅使用FaaS来实现其应用程序的一小部分：

“我们正在做很多混合——例如，你可以只将认证功能放在 Lambda上，而其余的代码则运行在标准 EC2上。” I4。

一个可能的原因是，将网页应用程序迁移到无服务器架构的常见模式是逐步从单体应用中“剥离”功能，并将其重新实现或迁移至无服务器架构。正如一位受访者所说：

“我认为一个好的规则是将你的应用程序分解成越来越小的函数，这样你就能更轻松地在图中进行划分，并移动一个[函数]和另一个之间的边界。” I1.

然而，我们的调查回复并不支持许多FaaS应用程序实际上以这种方式构建的观点（图 13）。58%的受访者认为，他们很少或从不逐步迁移现有应用程序。

总结：函数即服务被用于面向用户的应用和后端实用工具。然而，如果在面向用户的请求周期内使用，则需要克服一些技术上的挑战，其中最重要的是尾部延迟较慢。函数即服务特别适用于事件驱动应用或面临突发性工作负载且大部分时间处于空闲状态的应用。对于包含长时间运行任务或有较强性能要求的应用，此类服务不太适用。通常采用混合模型使用函数即服务，即与虚拟机或容器等传统云服务结合使用。

4.3. 应用模式

我们现在讨论在研究中观察到的常见应用模式。

应用规模。关于应用程序和系统中使用的函数数量和规模，受访者在很大程度上描绘了相似的情况。通常，5到15个函数被组合起来形成或补充一个应用或系统。仅有两位受访者报告了包含数十个函数的较大系统。

调查受访者的回答支持这一发现，如图14所示。近三分之二的受访者在每个应用或系统中使用一到十个函数。

单个函数提供的功能通常被设计得相对原子化。根据受访者的说法，函数的作用范围旨在反映特定的业务需求，或对应于一个REST API的操作。

常见模式。从我们的访谈和文献综述中得出的一个特别有趣的结果是，工业级FaaS解决方案中存在一些反复出现的模式，用于应对技术或概念上的局限性，例如最大超时时间过短或处理API网关的复杂性。我们将观察到的这些模式称为外部化状态（所有状态都存储在外部数据库中）、路由函数（配置一个中心函数接收所有请求并进行分发）、函数链（一个函数调用另一个函数以延长超时时间）、函数心跳（周期性地使用人工负载“心跳”函数，以防止FaaS平台丢弃所有容器）以及超大函数（单纯为了部署到更快的物理机上而为函数配置过高的内存需求）。我们在表2中对这些模式进行了概述。值得注意的是，除了外部化状态之外，所有这些（反）模式都可以看作是开发者在应对FaaS固有局限性时所做的努力和变通。

在图15中，我们总结了这些模式在我们的调查受访者中的使用普遍程度。外部化状态是迄今为止最常见的一种模式，有三分之二的参与者表示他们至少有时会使用它。17名受访者（18%）在构建函数即服务应用程序时总是采用外部化状态。其余模式的使用频率较低，这并不令人意外，因为这些模式属于变通方案某种程度上是利基约束和问题，而非实际的最佳实践。然而，其余四种模式都被报告为至少偶尔被使用，这表明函数即服务模型施加的局限性至少在某些时候对开发者构成了限制。

总结： 当前的函数即服务应用通常规模较小，且经常由10个或更少的函数组成。开发者使用var‐各种 应用 模式 和 变通方法 以应对 当前 函数即服务 平台固有的 局限性 。

4.4. 开发语言和实践

我们观察到，用于实现无服务器解决方案的编程语言种类较少。在大多数云平台上，JavaScript、Python以及在较小程度上的 Java 占据主导地位。在 Azure 上，C# /.NET 毫不意外地具有重要意义。这一点也在我们的调查中得到了体现：在回答此问题的 96 名受访者中，74% （71 人）使用了 JavaScript（无论是否结合 Node.js）、Python 或 Java。图16 详细列出了调查中的回答情况。这些结果一方面表明了开发者在编写函数时的偏好情况，还取决于提供了哪些语言。例如，在图16中标记为“其他”的8个回答中，有5个包含了“Go”，而Go语言是在我们的调查已经开始后才在谷歌的函数即服务产品中提供的。

开发挑战。鉴于该技术相对不成熟，我们观察到一些挑战和问题，即使是高级从业者目前也难以应对，这并不令人意外。一个主要挑战是如何测试函数。由于单个函数的规模相对较小且通常复杂度较低，因此非常适合进行可在本地执行的单元测试。然而，多个函数或外部服务的集成测试则更加困难，因为通常无法或很难实现整个系统的本地复制。

“[…]无法在您的本地机器上复制无服务器或云系统。” I6.

一种可能的解决方案是在生产环境中直接测试函数，或在同样托管于云中的专用开发环境中进行测试。实现后一种方案的常见方法是，在云服务提供商处创建多个独立账户，分别用于生产环境以及开发和测试。

这两种方法都有一个明显的缺点，即开发者需要为测试调用支付与生产工作负载相同的费用。此外，我们观察到，在实际生产环境中进行测试在某些情况下可能对生产系统产生（负面）副作用。解决此问题的一种方法是实施金丝雀发布或A/B测试，以便针对少量请求评估可能产生的副作用。

调查受访者的测试实践如图17所示。正如预期，单元测试通常在本地进行。在集成测试方面，专用的开发环境和模拟环境比生产环境（无论是常规方式，还是通过金丝雀发布或A/B测试）更常被用于测试。该问题的23.7%（22人）的受访者同时在专用的函数即服务开发环境和模拟的函数即服务环境中进行测试，而仅有16.1%（15人）的受访者在专用环境（开发或模拟）和生产环境中都进行测试。

另一个核心挑战是缺乏工具链和文档不足。对于受访者而言，部署 （一组）函数、将事件映射到函数（例如，使用 API 网关使函数可被 HTTP 请求访问）以及监控和日志记录等方面尤其需要工具链支持。然而，目前可用的工具中实际被使用的却很少。在调查受访者中，有 79.7% 使用了无服务器框架，这使其成为迄今为止最常用的工具。相比之下，第二常被提及的库 Chalice 仅被 11.6% 的受访者提及。这表明，除无服务器框架外，现有工具链似乎未能解决开发者当前面临的核心挑战，或者这些工具的存在尚未被广泛知晓。

此外，受访者认为现有的文档不够充分，特别是关于函数即服务的最佳实践仍在不断发展。在部署函数方面，一位受访者表示。

“（⋯⋯） there are really not a whole lot of accepted patterns or of the art solutions[how to deploy functions]。” I1.

承认这些不足， I1和 I3 （在一家主要的函数即服务提供商工作） 强调，他们当前的优先事项之一是改进其产品文档。

总结： JavaScript、 Python、 Java 和 C# 目前是函数即服务 服务的主流实现语言。当前构建函数即服务解决方案的主要开发挑战包括（集成）测试应用程序，以及缺乏良好的工具链和文档。

4.5. 优点和挑战

我们现在讨论采用函数即服务的优点和挑战。对于后者，我们更关注架构上和战略上的困难，而非前一节中讨论的技术上的开发挑战。

优点。我们观察到，开发者使用FaaS服务的动机可分为三类优势，即与业务相关的、技术上的以及与安全相关的优势（见图18）。这与此前关于云计算的报告结果一致（奇托等，2015）。

在业务优势方面，受访者认为FaaS通常采用的按需付费定价模式是一个重要因素。它确保了成本与使用量相对应，特别是能够在无使用时避免任何成本。因此，即使预期使用量很少或没有使用，函数也无需因成本原因而被“取消配置”或“未部署”。此外，由于FaaS使开发者无需自行管理服务器，他们可以投入更多时间专注于业务功能，相比在自有硬件或虚拟机上运行应用程序时更为高效。尽管FaaS要求开发者编写一些“管理代码”，例如用于部署相关函数组，这一观察结论仍然成立。

FaaS的部署流程普遍被认为比其他类型的云服务更简单，从而进一步节省了时间。

“（⋯⋯） 我们有很多 集成 是在， 比如说， 一周内完成的。 而几乎 每一个与外部 服务 （如 SAP 或 客户关系管理 或服务总线）的集成， 都需要一个高级开发团队花费数个冲刺周期才能完成。” I9。

使用函数即服务（FaaS）的另一个与成本相关的方面是，FaaS 的按请求计费模式能够实现直接的部署成本优化。本质上，FaaS 函数每快执行一毫秒，就能直接转化为成本节约。这使得从部署成本的角度来判断某些代码级别的优化是否“值得”变得更加容易。

在技术优点方面，受访者认为函数的弹性可扩展性是一个主要的技术优势。当需求增加时，FaaS提供商将对函数进行水平扩展。由于函数运行时间较短，在执行完成后会自动缩减规模。因此，FaaS为用户提供了无需任何配置 effort 的弹性可扩展性。受访者认为这是一个显著的优点，尽管目前尚无受访者报告在大规模环境中使用FaaS。此外，受访者欢迎FaaS的故障转移能力。如果函数执行失败，可以在无需显式配置或编码的情况下自动重试。

无服务器一个讨论较少的优势是，它还可以提高应用程序的安全性。函数即服务将管理和维护机器的负担转移给了云提供商，而这些提供商更有可能及时为机器打补丁：

“无服务器实际上消除了当今成功攻击的主要来源——未打补丁的服务器。这类服务器使用了带有已知漏洞的二进制文件，因为它们未应用这些依赖项的最新安全更新。” A8.

另一个方面是，（分布式）拒绝服务（DDoS）攻击会演变为计费问题而非可用性问题。传统系统在遭受DDoS攻击时可能会变得不可用，而基于函数即服务的解决方案则会自动扩展以应对负载，从而可能产生显著增加的成本。这是否优于停机，当然取决于具体上下文和应用场景。

挑战。与这些优点相比，受访者也提出了FaaS或无服务器计算普遍存在的挑战。其中一些挑战可能源于FaaS服务的相对不成熟，而另一些则是FaaS底层概念和实践所带来的结果。图19总结了我们的调查受访者认为在使用FaaS时的重要挑战，按各项挑战被选择的频率排序（可多选）。

除了工具链缺乏和集成测试困难之外，供应商锁定也被视为一个紧迫的问题。所有主流的FaaS提供商都提供自定义功能集和API。此外，由于FaaS与其他云服务的紧密集成，将FaaS应用迁移到另一家提供商相当困难。尾部延迟和状态处理是另外两个常被提及的挑战。值得注意的是，招聘挑战以及缺乏对函数组合的支持（这两个方面在我们的访谈和灰色文献分析中显著浮现）仅被12%的调查受访者视为主要挑战。我们认为，这可能是因为当前使用FaaS构建的许多应用规模相对较小且较为年轻，因此在当今的工业实践中，函数组合和招聘问题尚未成为紧迫问题，当然这在未来几年可能会发生变化。

总结：函数即服务在业务方面具有优势（降低成本和提高开发者生产力），在技术方面具有优势（透明弹性和自动故障转移），以及在安全方面的优势（托管服务器，以及一定程度上对DDoS攻击的抵抗能力）。开发人员面临的主要挑战包括缺乏良好的工具链、集成测试困难、供应商锁定以及性能问题。

4.6. 部署成本

尽管成本降低通常被认为是推动FaaS采用的核心因素，但深入分析表明，这实际上是一个备受争议的话题。虽然我们所有的受访者都认为 FaaS极具成本效益，甚至在许多用例中完全免费，但我们对灰色文献的调查却呈现出不同的情况。在Hackernews上的在线文章或讨论中，许多从业者报告了因云账单意外高昂而产生的负面体验。部分原因可能在于其高度不透明的计费模型，导致用户无法清楚了解其部署各个部分的 “实际”成本。

“(…)所有这些在账单上都极难看懂（到底是哪个函数花费最多，什么时候花费的？你得自己去做高级的账单图表分析才行）(…) 就我个人而言，我觉得要花这么大的力气去读懂自己的账单，实在是荒谬。” Hackernews 评论者，A25。

此外，一些 FaaS 用户发现存在一些不明显的“陷阱”，可能导致代价高昂的错误。例如，FaaS 服务在处理特定触发器或事件失败时会自动重试，从而实现容错（Hummer 等，2012）。然而，在某些情况下，用户遇到了无限循环问题，函数不断尝试处理相同的格式错误输入，直到手动终止为止。

“重试 可能 会 极大地增加 你的 账单 如果 某些事情 出错的话。” Hackernews 上的评论者， A25。

我们推测，这些问题并未在我们的访谈研究中出现，因为我们的受访者均为经验丰富的云开发者，不太可能陷入此类陷阱。总体而言，我们发现了从业者之间存在两条明显的分歧：一部分从业者认为函数即服务成本低廉，而另一部分则不这么认为。

首先，初创企业的开发者往往认为函数即服务成本低廉，而用户基数较大的公司的开发者则不这么认为。这是由于广泛的免费层级导致初创企业观察到的成本偏低。然而，对于持续的大规模使用，许多用户发现超出免费层级后的价格标签可能会变得相当显著，尤其是当用户需单独支付各项费用时

（几乎）每个正在使用的生态系统服务，例如在亚马逊网络服务中的 API网关、Lambda、S3 和 Step Functions。鉴于无服务器应用程序 如第4.1节所述本质上是组合性的，这很容易累积起来。

“我觉得这里‘无服务器更便宜’的观点在很大程度上是由那些最 热衷于尝试它的公司推动的——这些小型初创企业过早地为扩展性进行设计。” Hackernews 评论者，A9。

其次，将FaaS用作“胶水代码”的开发者往往认为FaaS成本低廉，而将其用于面向用户应用的开发者则不这么认为。在后端使用场景中，请求总量通常较低，这使得按调用计价模型比支付一个即使很小的容器或虚拟机的费用要便宜得多。然而，一旦每个用户请求都会调用FaaS函数，调用次数就会增加，成本也随之上升。当FaaS函数实际上持续执行时，直接预先支付虚拟机或容器的费用反而会比按请求计费的计算更便宜，这一点并不令人意外。另一个需要考虑的因素是，特别是API网关，一项AWS服务，在与用于面向用户应用的Lambda结合使用时几乎是必需的，但据称其价格特别昂贵。

“无服务器的强大之处在于，当你没有流量或系统不繁忙时，你不会消耗太多资源。” I11。

在我们的调查中，93%的受访者表示他们认为函数即服务成本低廉，或者根本不关心成本（图20）。然而，我们提醒读者，这可能是由于自我选择偏差所致：认为函数即服务昂贵的开发者不太可能自愿参与关于该主题的在线调查。

总结：尽管函数即服务服务通常具有成本效益，但这可能归因于 generous 免费层级和低利用率的使用情况。使用附加服务可能会轻易增加应用程序的总部署成本。高度不透明的计费模型使成本规划变得复杂。

5. 影响

本研究的结果揭示了对函数即服务提供商、消费者（即应用程序或系统开发者）以及研究人员的影响，我们将在以下小节中进行阐述。

5.1. 提供商的未来发展 方向 与 展望

FaaS服务仍处于相对较新的阶段，其初始发布包括：2014年11月发布的AWS Lambda、2016年2月发布的IBM Cloud Functions / OpenWhisk、2016年3月发布的Azure Functions，以及2017年3月发布的（测试版）Google Cloud Functions。因此，截至目前，这些服务通常会持续增加新功能，包括对新语言的支持以及与其他云的集成服务，或用于测试或组合的工具链。11我们的研究揭示了对各种进一步改进的需求。有趣的是，我们观察到代表平台提供商的受访者（例如 I1 或 I3）期望未来的无服务器解决方案将与当今的情况有根本性的不同，而代表无服务器用户的受访者则大多期望“更快的马”，即对现有解决方案的渐进式改进。这些更渐进式的改进分为两类：更好的工具链和解除限制。

提供更好的工具。鉴于当前函数即服务工具链的严重局限性，大多数受访者希望并期待未来能够提供更完善、更先进的用于开发无服务器解决方案的工具链，这并不令人意外。其中最重要的是改进测试和调试手段，例如支持云事件的记录与回放测试工具、可发布的云镜像（让用户能够在本地更准确地模拟云环境行为），以及能够直接连接到在云中运行的函数的调试器。Azure 已通过与 Visual Studio 的集成提供了许多此类功能。本研究的参与者普遍期望其他提供商也将跟进。

解除限制。此外，许多受访者预计提供商将逐步放宽当前模型的一些基本限制（例如与状态、执行时间限制等相关的限制），或至少提供更好的技术来规避这些限制。最重要的是，许多受访者期望提供商能够开发对有状态函数的支持，或通过平台提供一种集成的方式来处理特定类型的状态。在更广泛的生态系统中，已经出现了如FaunaDB等新型数据库设计，专门解决外部状态绑定的延迟问题。尽管在函数中引入部分有状态特性会影响性能，且提供商可能会相应调整定价，但该功能对开发者仍具有吸引力，因为它能够将更多传统设计的代码作为函数进行部署。I3认识到在面向终端用户的Web应用中支持连接池或缓存的必要性：

“许多网页系统使用内存缓存，比如Redis，你可以将它们与无服务器结合使用，但就内存缓存而言，鉴于你无法保证拥有持久性内存 ⋯⋯” I3.

来自代表提供商和工具构建者的受访者（I1、I3 和 I6）提出了另一组未来发展方向。这些受访者预计，未来的更新将相当根本性地改变无服务器技术的格局，尤其是在函数复用和生态系统、高层抽象、面向内存的无服务器技术以及边缘无服务器技术方面。

促进函数复用和生态系统发展。如第4.1节所述，目前尚缺乏支持云租户之间、甚至同一租户不同应用之间进行结构化函数复用的基础设施。I3认为，未来的函数即服务解决方案将自然包含一个函数生态系统，用户可以通过搜索引擎、目录或函数包发现现有的外部函数，包括用于特定任务的函数。现有的函数市场，例如Amazon无服务器应用程序仓库，显然是朝着这一方向迈出的重要一步，但目前似乎在推广方面存在困难。

更完善的函数市场将提高函数的复用性，使无服务器应用开发更具组合性。这些函数生态系统可能运行方式与当前的开源生态系统类似例如如 NPM （ Serebrenik和 Mens，2015 ）

提供高层抽象。FaaS 用户和 FaaS 平台的开发者都认为，当前平台、语言和服务所提供的开发模型相当初级。尽管已经迈出了初步步伐，尝试为无服务器应用提供类似“编程语言”的支持（例如 AWS Step Functions 服务，允许将应用程序描述为 FaaS 函数的工作流），但我们的部分受访者认为这些仅是第一步：

“（…） Step 函数的格式本质上就像一种汇编语言（…）没有人愿意为拥有数百个状态的状态机编写JSON格式。” I1.

人们预期，未来将开发出更高级别的抽象，而当前的技术（如 Lambda 和 Step Functions）将仅成为部署平台，不再用于直接编程。相反，我们可能会看到通用或特定领域的语言兴起，这些语言可编译为可在无服务器平台上部署的格式：

“我们将拥有能够编译出可在无服务器平台上执行内容的编程语言。” I1.

提供“面向内存的无服务器技术”。正如所讨论的，目前我们已经有了针对所有常见计算资源的按需无服务器技术，但内存除外。内存仍然只能通过基础设施即服务（如弹性计算云或ECS）或函数即服务（如 Lambda）与计算时间结合获取。I3预计，我们也将看到针对内存的类似服务的发展。从现实角度来看，如果符合其商业模式，提供商可利用虚拟机管理程序和容器引擎中的动态分配（内存膨胀）技术进行垂直扩展，以满足这一需求。

提供 “边缘端的无服务器技术 ”。一项正在进行中的发展是不仅在云中，而且直接在边缘设备上支持函数执行。 I5将此视为无服务器和FaaS的未来“杀手级应用”：

“实际上能够在 CloudFront的边缘执行代码 ，这非常热门。” I5。

从商业角度来看，现有的边缘和内容分发网络在升级函数处理能力后可能会成为游戏规则的改变者，因为它们的安装基础仍远大于主要 FaaS提供商，但迄今为止作者尚不了解在此方向上的具体计划。

5.2. 开发者接下来该何去何从

对于开发者而言，FaaS 的当前状态似乎是一把双刃剑：一方面， FaaS 提供了巨大的潜力，能够实现自动扩展和弹性，减少部署和服务器管理所需的工作量，并且（通常）降低部署和开发成本；另一方面，当前 FaaS 服务及其相关工具链的局限性，以及需要采用相应的思维模式，为开发者带来了需要克服的挑战。

请评估您的使用场景是否适合函数即服务。我们的调查发现，函数即服务既被用于后端应用，也被用于面向终端用户的应用——既可以独立使用，也可以与其他服务结合使用。然而，许多受访者对第二种使用场景持怀疑态度，例如指出响应时间和尾部延迟限制，以及在跨请求的状态处理方面存在的挑战（例如持久化会话）。在考虑使用函数即服务时，开发人员应仔细评估其在状态处理、预期工作负载和运行时方面的需求，以及非功能性需求方面，例如，内存 、处理能力、响应时间以及成本 ——无论是对于使用函数即服务还是替代方案。

接受FaaS的思维模型。该模型促进了从作为函数实现的小型服务进行应用与系统的组合，以及与其他云服务的集成。我们的研究发现表明，由于FaaS与现有技术和方法相近，培训经验丰富的开发者可能较为容易，同时也有理由相信初级开发者可以轻松地将这一思维模式默认采纳，这些结论应鼓励开发人员（见第4.1节）。

谨慎选择要使用的提供商。在选择具体的FaaS提供商时，开发者一方面应考虑与其他云服务集成的可能性以及所需的工作量，这是FaaS使用中的常见模式。如果他们已经依赖某一提供商的多种服务，则集成 FaaS可能会更加容易，并且可以（重新）使用熟悉的工具。另一方面，开发者需要仔细评估几乎所有现有服务中普遍存在的供应商锁定问题。

预见您的工具链需求——尤其是在测试方面。受访者和调查受访者均指出，当前围绕函数即服务的工具链缺乏是一个核心挑战。这一点在测试领域尤为明显，大多数受访者依赖本地单元测试。而集成测试则难以实现，因为缺乏模拟平台，且在生产环境中进行测试可能产生副作用并增加成本。开发人员在开发基于函数即服务的应用程序和系统之前，应考虑潜在的测试需求，并结合其FaaS提供商所提供的特定支持。

5.3. 研究人员的下一步方向

对于研究人员而言，我们的工作带来了三个主要影响：首先，系统与软件工程研究可以解决前几个小节中讨论的提供商和开发者所面临的已识别挑战。其次，需要开展实证研究（如本文）来评估函数即服务的使用情况以及所提供服务的发展演变。第三，随着关于函数即服务的研究日益增多，有必要开展元研究来对发现进行情境化、关联和总结。

改进和扩展与FaaS相关的软件。旨在改进FaaS系统的研究所产生的影响，取决于这些目标系统是否真正被开发者在实践中所采用。根据我们的研究发现，FaaS目前正处于快速发展的无服务器计算生态系统的核心。然而，许多工具仍属于第一代原型，具有巨大的优化潜力。因此，我们建议研究人员超越孤立的单项贡献，转而考虑涵盖运行时环境、开发者工具链以及混合无服务器/传统应用开发的整体性无服务器应用用例。

研究FaaS服务的使用。正如本研究所要做的那样，实证研究可以突出当前FaaS服务在软件工程角度的各种方面，包括优势、劣势和挑战、经济激励或采用障碍，以及对系统和应用设计的影响。尽管我们将本研究视为一个起点，但我们更侧重于广度而非深度，例如并未深入研究功能集开发以及随时间推移对软件开发者行为的影响。我们认为此类后续研究将是极具价值的贡献，可指导软件开发者构建无服务器解决方案。

确定使用函数即服务的实际成本。正如我们在研究中发现的，关于函数即服务是否比其他云服务更具成本效益，以及适用于哪些应用程序的问题，并不容易回答。研究人员应与企业开展案例研究，以全面了解所涉及的各种成本和收益，包括开发成本 、提高的业务敏捷性以及按需付费与按时付费 之间的区别。目前的情况是 ，开发者在这些方面难以做出明智的决策 ，并无法区分云服务提供商的营销宣传与客观事实 。

与工业实践保持一致。此外，我们的研究方法直接带来了后续研究的可能性。从学术影响的角度来看，特别值得关注的是开发者所采用的技术选择与研究人员所采用的技术选择之间的匹配情况。据非正式观察，我们发现两者之间存在不匹配，尤其是在函数组合和函数测试等高级主题方面，这些主题在当前的科学文献中涉及较少，但在实践中却显得极为重要。我们建议利用本研究的结果来指示哪些领域实际上需要未来的概念性改进。

6. 相关工作

FaaS平台已成为大量已发表研究成果的主题。研究领域涵盖科学计算中的云函数（Ishakian 等，2017；Spillner 等，2017）、边缘计算、数据处理分析等其他应用领域以及经济方面。关于无服务器计算研究活动和文献的全面概述，可参考无服务器计算国际研讨会参与者提供的总结（Fox 等，2017）以及《无服务器文献数据集》（Spillner，2018）。Cito等人（2015年）还提出了一项关于云环境下的软件开发实践的更广泛调查。其中报告的主要主题（例如，采用由业务和技术因素共同驱动）同样在我们的研究中显现出来。

我们的研究主题与基于微服务的软件开发相关研究领域之间存在密切关系（Buchgeher 等，2017）。Pahl 和 Jamshidi 所做的一项较早的系统映射研究为这一相关领域提供了良好的概述（Pahl 和 Jamshidi，2016）。Balalaie 等报告了一项关于迁移到微服务的案例研究（Balalaie 等，2016）。他们认为，渐进式迁移以及对托管服务和重用的高度重视对于微服务项目的成功至关重要，这与我们的研究发现一致。Mazlami 等研究了从单体应用中切分微服务的各种自动化度量方法，这些方法也可能适用于无服务器和函数即服务的迁移（Mazlami 等， 2017）。工作流与编排系统不仅出现在第2.5节所介绍的云函数中，也出现在其他微服务架构中，例如用于 Spring Cloud组件 的 Beethoven（Barbosa 等，2018）。目前我们尚未发现有关微服务与主流云函数模型之间匹配程度的正式阐述，但所选的研究文献、我们的研究结果以及首批专注于该匹配问题的学术工作（Lloyd 等，2018）表明，大多数 FaaS 服务被广泛视为微服务实现技术。

考虑到已发布的与无服务器和函数即服务相关的研究成果，与关注运行时及更偏技术性问题的文章相比，聚焦于开发视角的研究较少。因此，相关工作可分为三类：