Serverless无服务器架构系列二

继续上一篇：Serverless无服务器架构系列一

Serverless缺点

无服务器架构当然有很多值得喜欢的地方，但它们有着重要的权衡。其中一些权衡是这些概念所固有的；它们不能完全由进展来解决，而且它们总是需要考虑的。其他的则与当前的实现有关；随着时间的推移，我们可以期望看到这些问题得到解决。

固有缺点：

供应商控制

对于任何外包策略，您都是在将部分系统的控制权交给第三方供应商。这种缺乏控制可能表现为系统停机、意外限制、成本变化、功能丧失、强制API升级等。我之前提到的慈善专业人士在本文的权衡部分更详细地解释了这个问题：

[供应商服务]，如果它是智能的，将对您如何使用它施加强烈的限制，因此他们更有可能实现其可靠性目标。当用户拥有灵活性和选择时，就会产生混乱和不可靠。如果平台必须在你的幸福感和成千上万其他客户的幸福感之间做出选择，那么他们每次都会选择多个而不是一个——这是他们应该做的。

--慈善专业

多租户问题

多租户是指多个不同客户（或租户）的多个软件实例在同一台机器上运行，并且可能在同一托管应用程序中运行的情况。这是我们前面提到的实现规模效益经济的战略。服务供应商尽其所能让客户觉得只有他们自己在使用他们的系统，而通常优秀的服务供应商在这方面做得很好。但是，任何一个完美的解决方案（有时是多租户解决方案）都不会在安全性（一个客户能够看到另一个客户的数据）、健壮性（一个客户的软件中的错误导致另一个客户的软件出现故障）和性能（高负载客户导致另一个客户的速度减慢）方面出现问题。

这些问题不是无服务器系统独有的，它们存在于许多其他使用多租户的服务产品中。AWS Lambda现在已经足够成熟了，我们不希望看到它出现这种问题，但是您应该注意任何不太成熟的服务，无论是来自AWS还是其他供应商的服务。

厂商锁定

很可能，无论您从一个供应商使用什么无服务器功能，另一个供应商都会以不同的方式实现。如果您想更换供应商，您几乎肯定需要更新您的操作工具（部署、监视等），您可能需要更改您的代码（例如，满足不同的FaaS接口），如果竞争供应商实现的行为存在差异，您甚至可能需要更改您的设计或体系结构。

即使您能够轻松地迁移生态系统的一部分，您也可能会受到另一个体系结构组件的更大影响。例如，假设您正在使用AWS Lambda响应AWS Kinesis消息总线上的事件。AWS Lambda、Google Cloud函数和microsoftazure函数之间的差异可能相对较小，但您仍然无法将后两个供应商实现直接连接到您的AWS Kinesis流。这意味着，如果不同时移动基础设施的其他部分，就无法将代码从一个解决方案移动或移植到另一个解决方案。

很多人都被这个想法吓坏了，如果你今天选择的云供应商明天需要改变，那么你还有很多工作要做，这不是一种很好的感觉。正因为如此，一些人采用了“多云”方法，以一种与实际使用的云供应商无关的方式开发和操作应用程序。通常，这比单一云方法的成本更高，因此尽管供应商锁定是一个合理的问题，但我仍然建议选择一个您满意的供应商，并尽可能多地利用他们的能力。我将在本文中详细讨论这一点的原因。

安全问题

采用无服务器的方法会让您面临大量的安全问题。这里只是一个非常简短的事情要考虑一定要探索什么其他可能影响你。

• 您使用的每个无服务器供应商都增加了生态系统所采用的不同安全实现的数量。这会增加恶意攻击的表面积，并增加成功攻击的可能性。
• 如果直接从移动平台使用BaaS数据库，您将失去服务器端应用程序在传统应用程序中提供的保护屏障。虽然这不是一个破坏者，但在设计和开发应用程序时确实需要非常小心。
• 当您的组织接受FaaS时，您可能会在整个公司经历寒武纪FaaS功能的爆炸。这些函数中的每一个都为问题提供了另一个向量。例如，在AWS Lambda中，每个Lambda函数通常与一个配置的IAM策略并行，这很容易出错。这不是一个简单的话题，也不是一个可以忽略的话题。IAM管理需要仔细考虑，至少在生产账户内。

跨客户端平台重复逻辑

在“完整”的BaaS架构中，服务器端没有编写任何自定义逻辑，所有这些都在客户机中。对于您的第一个客户机平台来说，这可能很好，但是一旦您需要下一个平台，您就需要重复实现该逻辑的一个子集，在更传统的体系结构中就不需要这种重复了。例如，如果在这种系统中使用BaaS数据库，那么您的所有客户端应用程序（可能是web、本机iOS和本机Android）现在都需要能够与供应商数据库通信，并且需要了解如何从数据库模式映射到应用程序逻辑。

此外，如果您想在任何时候迁移到一个新的数据库，您都需要在所有不同的客户机之间复制编码/协调更改。

服务器优化丢失

有了完整的BaaS体系结构，就没有机会为客户机性能优化服务器设计。“后端到前端”模式的存在是为了在服务器中抽象出整个系统的某些基本方面，部分原因是为了在移动应用程序中客户端可以更快地执行操作并使用更少的电池电量。这种模式不适用于完整的BAA。

对于所有自定义逻辑都在客户机中且只有后端服务由供应商提供的完整BaaS体系结构，这一点和前面的缺点都存在。这两种方法的一种缓解方法是采用FaaS或其他某种轻量级服务器端模式，将某些逻辑移动到服务器上。

无服务器FaaS没有服务器状态

在讨论了几个BaaS特有的缺点之后，让我们来讨论一下FaaS：

当涉及到本地时，FaaS功能有很大的限制。。状态。。您不应该假设一个函数的一次调用的状态将可用于同一函数的另一次调用。

这种假设的原因是，对于FaaS，我们通常无法控制函数的宿主容器何时启动和停止。

我之前也说过，地方政府的另一种选择是遵循12因素应用程序的第6个因素，也就是接受这个约束：

12因素进程是无状态的，不共享任何内容。任何需要持久化的数据都必须存储在有状态的备份服务中，通常是数据库。

--十二要素应用程序

Heroku推荐这种思维方式，但是在运行PaaS时可以改变规则，因为您可以控制Heroku Dynos的启动和停止时间。有了联邦航空局，就不能违反规则。

那么，如果你不能把FaaS保存在记忆中，你的状态会怎样呢？上面的引用是指使用数据库，在许多情况下，快速NoSQL数据库、进程外缓存（例如Redis）或外部对象/文件存储（例如S3）将是您的一些选择。但这些都比内存或机器持久性慢得多。你需要考虑你的申请是否适合这个职位。

这方面的另一个问题是内存缓存。许多从外部存储的大型数据集读取数据的应用程序将保留该数据集一部分的内存缓存。您可能正在从数据库中的“引用数据”表中读取数据，并使用类似Ehcache的方法。或者，您可以从指定缓存头的HTTP服务读取数据，在这种情况下，内存中的HTTP客户机可以提供本地缓存。

FaaS确实允许使用一些本地缓存，假设函数使用频率足够高，这可能会很有用。例如，对于AWS Lambda，我们通常希望函数实例能够保持几个小时，只要它每几分钟至少使用一次。这意味着我们可以使用Lambda提供的3gbram（可配置）或512mb本地“/tmp”空间。对于某些缓存，这可能就足够了。否则，您将不再需要假定进程内缓存，而需要使用低延迟外部缓存，如Redis或Memcached。但是，这需要额外的工作，并且可能会非常慢，这取决于您的用例。

实施缺陷

前面描述的缺点在无服务器的情况下可能总是存在的。我们将看到缓解方案的改进，但它们永远都会存在。

然而，剩下的缺点完全归结为目前的技术水平。有了供应商和/或英雄社区的意愿和投资，这些都可以被消灭。事实上，从本文的第一个版本开始，这个列表已经缩小了。

配置

当我编写本文的第一个版本时，AWS在Lambda函数的配置方面提供的很少。我很高兴地说，这个问题现在已经解决了，但是如果您使用的是一个不太成熟的平台，那么它仍然值得检查。

做你自己

下面是一个例子，说明了为什么在处理FaaS时，caveat emptor是一个关键短语。AWS Lambda限制在给定时间可以运行的Lambda函数的并发执行数。假设这个限制是1000；这意味着在任何时候都可以执行1000个函数实例。如果需要进行以上操作，则可能会出现异常、排队和/或一般性减速。

这里的问题是，这个限制是跨整个AWS帐户的。一些组织在生产和测试中使用相同的AWS帐户。这意味着，如果您组织中的某个地方有人执行一种新类型的负载测试，并开始尝试执行1000个并发Lambda函数，那么您将意外地关闭生产应用程序。哎呀。

即使您使用不同的AWS帐户进行生产和开发，一个过载的生产lambda（例如，处理来自客户的批量上载）可能会导致您的独立实时lambda支持的生产API变得无响应。

Amazon通过保留并发在这里提供了一些保护。保留并发允许您限制Lambda函数的并发性，以便它不会破坏帐户的其余部分，同时确保无论帐户中的其他函数在做什么，总是有可用的容量。但是，帐户的保留并发在默认情况下不会打开，需要仔细管理。

执行持续时间

在本文前面我提到，如果AWS Lambda函数运行时间超过5分钟，它们将被中止。这已经持续了好几年了，AWS也没有任何改变的迹象。

启动延迟

我之前谈到了冷启动，并提到了我关于这个主题的文章。随着时间的推移，AWS已经改进了这一领域，但是这里仍然存在重大的问题，特别是对于偶尔触发的JVM实现的函数和/或需要访问VPC资源的函数。预计这方面将继续改善。

好吧，这已经够专门挑AWS Lambda了。我敢肯定其他供应商也有一些相当丑陋的骨架勉强在他们的衣柜。

测试

无服务器应用程序的单元测试非常简单，原因我在前面已经讨论过：您编写的任何代码都是“代码”，而且在大多数情况下，您不必使用一大堆自定义库或实现接口。

另一方面，集成测试无服务器应用程序很难。在BaaS世界中，您故意依赖外部提供的系统，而不是您自己的数据库。那么您的集成测试是否也应该使用外部系统呢？如果是，那么这些系统对测试场景的适应性如何？你能轻易地撕毁和拆毁国家吗？您的供应商能否为负载测试提供不同的计费策略？

如果您想存根这些外部系统进行集成测试，供应商是否提供本地存根模拟？如果是这样，存根的保真度有多好？如果供应商不提供存根，您将如何实现自己的存根？

FaaS土地也存在同样的问题，尽管这方面有所改善。现在可以在本地为Lambda和microsoftazure运行FaaS函数。但是，没有一个本地环境可以完全模拟云环境；我不推荐仅依赖本地FaaS环境。事实上，我进一步建议您运行自动化集成测试的规范环境（至少作为部署管道的一部分）应该是云，并且您应该主要使用本地测试环境进行交互式开发和调试。这些本地测试环境在不断改进—例如，SAM CLI为开发基于Lambda的HTTP API应用程序提供了快速反馈。

考虑集成测试是一件大事的部分原因是，我们与无服务器faa的集成单元（即每个函数）比与其他体系结构的集成单元小得多，因此我们对集成测试的依赖比与其他体系结构样式的集成测试要大得多。

调试

使用FaaS进行调试是一个有趣的领域。这里已经取得了一些进展，主要与本地运行FaaS函数有关，与上面讨论的测试更新保持一致。正如我前面提到的，Microsoft为本地运行但由远程事件触发的函数提供了出色的调试支持。亚马逊提供了类似的服务，但还没有被生产事件触发。

在生产云环境中实际运行的调试函数是另一回事。Lambda至少还不支持这一点，尽管看到这样的功能会很好。

部署、打包和版本控制

这是一个正在积极改进的领域。AWS在改进这方面已经取得了巨大的进步，稍后我将在“无服务器的未来”一节中进一步讨论它。

发现

“发现”是微服务界经常讨论的话题：它是一个服务如何调用另一个服务的正确版本的问题。在没有服务器的世界里，很少有关于发现的讨论。起初我很担心，但现在我不那么担心了。无服务器的许多用法本质上是事件驱动的，在这里，事件的使用者在某种程度上通常是自注册的。对于FaaS面向API的用法，我们通常在API网关后面使用它们。在这种情况下，我们在API网关前面使用DNS，在网关后面使用自动部署/流量转移。我们甚至可以在API网关前面使用更多的层（例如，使用AWS CloudFront）来支持跨区域弹性。

我把这个想法留在“局限性”里，因为我认为它还没有被证明，但它最终可能会好起来。

监视和可观测性

由于集装箱的短暂性，监测对FaaS来说是一个棘手的领域。大多数云供应商都会为您提供一些监控支持，我们在这里也看到了许多来自传统监控供应商的第三方工作。不过，无论他们和你最终能做什么，都取决于供应商提供给你的基本数据。在某些情况下，这可能很好，但至少对于AWS Lambda来说，这是非常基本的。我们在这个领域真正需要的是开放的api和第三方服务的能力，以帮助更多。

API网关定义，以及雄心勃勃的API网关

虽然链接通常指的是API网关（例如，对于那些面向传统部署的微服务的网关），但它肯定可以应用于将API网关用作FaaS函数的HTTP前端。问题是API网关提供了在自己的配置/定义域中执行许多特定于应用程序的逻辑的机会。这种逻辑通常很难测试、版本控制，有时甚至难以定义。通常，这样的逻辑与应用程序的其余部分一样留在程序代码中要好得多。

不过这里肯定有点紧张。如果我们把一个API网关看作一个BaaS，那么为了节省我们的工作，考虑它给我们的所有选项不是很有价值吗？如果我们为每个请求使用一个API网关付费，而不是按CPU利用率付费，那么最大限度地利用API网关的功能不是更划算吗？

我的指导是明智地使用增强的API网关功能，并且只有在这样做从长远来看确实可以节省您的精力时，包括在如何部署、监视和测试它方面。绝对不要使用无法在源代码可控的配置文件或部署脚本中表达的API网关特性。

关于定义的困难，Amazon的API网关曾经强迫您创建一些复杂的配置来映射到Lambda函数的HTTP请求和响应。通过Lambda代理集成，大部分工作变得更加简单，但是您仍然需要了解一些偶尔会出现的微妙差别。使用诸如无服务器框架和克劳迪娅.js，或亚马逊的无服务器应用程序模型。

业务延期

我之前提到过，无服务器并不是“无操作”——从监控、体系结构扩展、安全性和网络角度来看，还有很多工作要做。然而，当你刚开始的时候很容易忽略操作（“看，妈，没有操作系统！”). 这里的危险正在被一种虚假的安全感所迷惑。也许你已经启动并运行了你的应用程序，但它意外地出现在黑客新闻上，突然你有10倍的流量要处理，哎呀！你不小心被打了，不知道怎么处理。

解决办法是教育。使用无服务器系统的团队需要尽早考虑操作活动，供应商和社区应该提供教学帮助他们理解这意味着什么。先发制人负载测试和混沌工程等领域也将有助于团队自学。

Serverless的未来

我们即将结束进入无服务器架构世界的旅程。最后，我将讨论一些我认为无服务器世界在未来几个月和几年可能发展的领域。

减轻缺点

无服务器仍然是一个相当新的世界。因此，上一节关于缺点的内容非常广泛，我甚至没有涵盖我所能拥有的一切。无服务器的最重要的发展将是减轻固有的缺陷，消除或至少改进实现缺陷。

工具

工具仍然是Serverless的一个关注点，这是因为许多技术和技巧都是新的。部署/应用程序绑定和配置在过去两年中都有所改进，无服务器框架和Amazon的无服务器应用程序模型引领了这一潮流。然而，“前10分钟”的体验仍然没有普遍的惊人，尽管亚马逊和谷歌可以向微软和Auth0寻求更多的灵感。

我很高兴看到云供应商正在积极解决的一个领域是更高级别的发布方法。在传统系统中，团队通常需要编写自己的流程来处理“流量转移”的想法，如蓝绿部署和金丝雀发布。考虑到这一点，Amazon支持Lambda和API网关的自动流量转移。这样的概念在无服务器系统中更加有用，因为在无服务器系统中，一次发布100个Lambda函数所需的系统原子级组件太多是不可能的。事实上，Nat Pryce向我描述了一种“混合台”方法的想法，在这种方法中，我们可以逐渐地将一组组件引入和退出交通流。

分布式监控可能是最需要改进的领域。我们从亚马逊的X射线和各种第三方产品中看到了早期的工作，但这绝对不是一个解决的问题。

远程调试也是我希望看到的更广泛的东西。Microsoft Azure函数支持此功能，但Lambda不支持。能够中断远程运行的函数是一种非常强大的功能。

最后，我希望看到“元操作”工具的改进——如何更有效地处理成百上千的FaaS功能、配置的服务等。例如，组织需要能够看到某些服务实例何时不再被使用（出于安全目的，如果没有其他目的的话），他们需要更好的分组和跨服务成本的可见性（特别是对于承担成本责任的自主团队），等等。

状态管理

FaaS缺少持久的服务器状态对于很多应用程序来说是好的，但是对于许多其他应用程序来说，无论是对于大型缓存集还是对会话状态的快速访问，这都是一个破坏。

对于高吞吐量应用程序来说，一个解决方法可能是让供应商在事件之间保持函数实例更长时间的活动，并让常规的进程内缓存方法来完成他们的工作。这并不是百分之百的工作，因为缓存不会对每个事件都是热的，但是对于使用自动伸缩的传统部署应用程序来说，这是同样的问题。

更好的解决方案可能是对进程外数据的低延迟访问，比如能够以极低的网络开销查询Redis数据库。考虑到Amazon已经在其Elasticache产品中提供了托管Redis解决方案，并且他们已经允许使用放置组对EC2（服务器）实例进行相对共定位，所以这似乎不算太长。

不过，更可能的情况是，我认为我们将看到不同类型的混合（无服务器和非无服务器）应用程序体系结构，以考虑外部化的状态约束。例如，对于低延迟应用程序，您可能会看到这样一种方法：一个常规的、长时间运行的服务器处理一个初始请求，从其本地和外部状态收集处理该请求所需的所有上下文，然后将一个完全上下文化的请求交给FaaS函数场，这些函数不需要在外部查找数据。

平台改进

目前，无服务器faa的某些缺点可以归结为平台的实现方式。执行持续时间、启动延迟和跨函数限制是三个明显的限制。这些问题可能会被新的解决方案所解决，也可能会有额外的成本。例如，我认为可以通过允许客户请求FaaS函数的两个实例总是在低延迟下可用，并由客户支付可用性费用，来减轻启动延迟。microsoftazure函数具有持久性函数和应用服务计划托管函数的思想。

当然，除了修复当前的缺陷之外，我们还会看到平台的改进，这些也将是令人兴奋的。

教育类

无服务器的许多特定于供应商的固有缺点正在通过教育得到缓解。每个使用此类平台的人都需要积极思考，让一个或多个应用程序供应商托管如此多的生态系统意味着什么。我们需要思考这样的问题，“如果一个供应商不可用，我们是否要考虑来自不同供应商的并行解决方案？”以及“在部分停机的情况下，应用程序如何正常降级？”

另一个教育领域是技术操作。许多团队现在的系统管理员比以前少了，而Serverless将加速这一变化。但是系统管理员不仅仅是配置Unix框和Chef脚本，他们通常是支持、网络、安全等方面的一线人员。

在一个没有服务器的世界里，真正的DevOps文化变得更加重要，因为那些其他非系统管理活动仍然需要完成，现在通常是开发人员负责这些活动。这些活动对许多开发人员和技术领导来说可能不是自然而然的，因此教育和与运营人员的密切合作至关重要。

提高透明度和供应商更明确的期望

最后，关于缓解问题：供应商将不得不更加清楚地了解我们对他们平台的期望，因为我们更多地依赖他们提供托管功能。虽然迁移平台很难，但并非不可能，不可靠的供应商会看到他们的客户将业务转移到其他地方。

模式的出现

我们对如何以及何时使用无服务器架构的理解还处于初级阶段。目前，各团队正在无服务器平台上抛出各种各样的想法，看看有什么吸引人。感谢开拓者！我们开始看到推荐实践的模式出现了，这种知识只会增长。

我们看到的一些模式在应用程序体系结构中。例如，FaaS函数在变得笨拙之前能有多大？假设我们可以原子化地部署一组FaaS函数，那么创建这种分组的好方法是什么？它们是否与我们目前如何将逻辑聚集到微服务中密切相关，还是架构上的差异将我们推向了不同的方向？

在无服务器应用程序体系结构中，一个特别有趣的活跃讨论领域是它如何与事件思维交互。AWS Lambda产品负责人Ajay Nair在2017年对此做了一次精彩的演讲，这也是CNCF无服务器工作组讨论的主要领域之一。

进一步扩展这一点，在FaaS和传统的“永远在线”持久服务器组件之间创建混合架构的好方法是什么？将BAA引入现有生态系统的好方法是什么？反过来说，一个完全或大部分BaaS系统需要开始接受或使用更多自定义服务器端代码的警告信号是什么？

我们还看到更多的使用模式被讨论。FaaS的一个标准示例是媒体转换，例如，每当一个大的媒体文件被存储到一个S3 bucket中，然后自动运行一个进程在另一个bucket中创建较小的版本。然而，我们现在也看到了无服务器在数据处理管道、高度可伸缩的webapi以及操作中作为通用“粘合”代码的重要用途。其中一些模式可以实现为通用组件，可以直接部署到组织中；我曾写过Amazon的无服务器应用程序存储库，它具有这种思想的早期形式。

最后，随着工具的改进，我们开始看到推荐的操作模式。我们如何在逻辑上聚合FaaS、BaaS和传统服务器的混合体系结构的日志记录？如何最有效地调试FaaS函数？这些问题和新兴模式的许多答案都来自云供应商本身，我预计这一领域的活动将会增长。

全球分布式体系结构

在我前面给出的Pet Store示例中，我们看到单个Pet Store服务器被分解为几个服务器端组件和一些逻辑，这些逻辑一直向上移动到客户端，但从根本上讲，这仍然是一个专注于客户端或已知位置的远程服务的体系结构。

我们现在开始看到，在这个没有服务器的世界里，责任的分配更加模糊。亚马逊就是一个例子λ@边产品：在Amazon的CloudFront内容交付网络中运行Lambda函数的方法。与λ@边一个Lambda函数现在是全球分布的——一个工程师的一个上传活动将意味着该函数被部署到全球100多个数据中心。这不是一个我们习惯的设计，它同时具有大量的约束和功能。

此外，Lambda函数可以在设备上运行，机器学习模型可以在移动客户端上运行，在你知道之前，“客户端”和“服务器端”的分歧似乎不再有意义。事实上，我们现在看到了一系列组件的局部性，从人类用户那里扩散开来。无服务器将变为无区域。

超越FaaS

到目前为止，我所看到的FaaS的大多数用法主要是采用现有的代码和设计思想，并将它们“faasing”：将它们转换为一组无状态函数。这是很强大的，但我希望我们将开始看到更多的抽象，可能还有语言，使用FaaS作为底层实现，给开发人员带来FaaS的好处，而不把他们的应用程序看作一组离散函数。

举个例子，我不知道Google的数据流产品是否使用FaaS实现，但我可以想象有人创建了一个做类似事情的产品或开源项目，并使用FaaS作为实现。这里的比较类似于apachespark。Spark是一个用于大规模数据处理的工具，它提供了非常高级的抽象，可以使用amazonemr和Hadoop作为其底层平台。

测试

我认为在无服务器系统的集成和验收测试方面还有更多的工作要做，但这方面的很多工作与以更传统的方式开发的“云本地”微服务系统是一样的。

这里一个激进的想法是接受生产中的测试和监视驱动的开发这样的想法；一旦代码通过了基本单元测试验证，就部署到通信量的子集，看看它与以前的版本相比如何。这可以与我前面提到的交通转移工具相结合。这并不适用于所有上下文，但对于许多团队来说，它可能是一个出人意料的有效工具。

可移植实现

团队可以通过几种方式使用无服务器，同时减少与特定云供应商的联系。

对供应商实现的抽象

无服务器框架的存在主要是为了简化无服务器应用程序的操作任务，但也提供了一定程度的中立性，即在何处以及如何部署此类应用程序。例如，即使是现在，根据每个平台的操作能力，能够在awsapi Gateway+Lambda和auth0webtask之间轻松切换也会很好。

其中一个棘手的方面是对抽象的FaaS编码接口进行建模，而没有一些标准化的想法，但这正是cncfserverless CloudEvents工作组的工作。

然而，一旦操作的复杂性浮现在他们的脑海中，为多个平台提供一个部署抽象有多大的价值是值得怀疑的。例如，为一个云获得正确的安全性在另一个云中总是可能是不同的。

可部署的实现

建议我们在不使用第三方提供商的情况下使用无服务器技术可能听起来有些奇怪，但请考虑以下想法：

• 也许我们是一个大型的技术组织，我们希望开始为我们所有的移动应用程序开发团队提供类似Firebase的数据库体验，但我们希望使用我们现有的数据库体系结构作为后端。
• 我之前谈到过“服务器式”FaaS平台能够在我们的一些项目中使用FaaS风格的体系结构，但是由于遵从法规、法律等原因，我们需要在本地运行应用程序。

在这两种情况下，使用无服务器方法仍有许多好处，而不必使用来自供应商托管的方法。这里有一个先例，即平台即服务（PaaS）。最初流行的PaaS都是基于云的（例如Heroku），但是，人们很快就看到了在自己的系统上运行PaaS环境的好处，即所谓的“私有”PaaS（例如，我在文章前面提到的cloudfoundry）。

我可以想象，就像私有PaaS实现一样，我们将看到BaaS和FaaS概念的开源和商业实现变得流行起来，尤其是那些与Kubernetes等容器平台集成的实现。

社区

目前已经有一个规模不错的无服务器社区，在许多城市有多个会议、聚会和各种在线群组。我预计这将继续增长，可能与Docker和Spring等社区的发展趋势相同。

小结

无服务器（Serverless）是一种体系结构，尽管名称令人困惑，但它依赖于将自己的服务器端系统作为应用程序的一部分来运行，其程度比通常要小。我们通过两种技术做到这一点：BaaS，将第三方远程应用程序服务直接紧密集成到应用程序的前端；FaaS，将服务器端代码从长期运行的组件移动到短暂的功能实例。

无服务器并不是解决所有问题的正确方法，所以要提防那些说它将取代所有现有体系结构的人。如果您现在要进入无服务器系统，尤其是在FaaS领域，请小心。尽管有丰富的可扩展性和节省的部署工作可供掠夺，但也有调试和监控的巨龙潜伏在下一个角落。

然而，这些财富不应该太快被忽略，因为无服务器体系结构有很多积极的方面，包括降低了操作和开发成本、简化了操作管理和减少了环境影响。但我认为最重要的好处是减少了创建新应用程序组件的反馈循环。我是“精益”方法的超级粉丝，主要是因为我认为尽快让技术出现在最终用户面前以获得早期反馈是很有价值的，而无服务器带来的缩短上线时间正好符合这一理念。