189 8069 5689
原文地址：https://martinfowler.com/articles/serverless.html
作者：Martin Fowler, Mike Roberts
十多年的郎溪网站建设经验，针对设计、前端、开发、售后、文案、推广等六对一服务，响应快，48小时及时工作处理。成都全网营销推广的优势是能够根据用户设备显示端的尺寸不同，自动调整郎溪建站的显示方式，使网站能够适用不同显示终端，在浏览器中调整网站的宽度，无论在任何一种浏览器上浏览网站，都能展现优雅布局与设计，从而大程度地提升浏览体验。创新互联建站从事“郎溪网站设计”,“郎溪网站推广”以来，每个客户项目都认真落实执行。
到目前为止，我们一直试图只定义和解释无服务器架构的含义。现在我将讨论这种设计和部署应用程序方法的一些优点和缺点。你绝对不应该在没有充分考虑并权衡利弊的情况下使用无服务器架构。
让我们从彩虹和独角兽的国度开始，看看无服务器架构的好处。
在最简单的情况下，无服务器架构是一个外包解决方案。它允许你花钱请人来管理服务器、数据库，甚至你自己管理的应用程序逻辑。由于你使用了许多其他人也将使用的预定义服务，因此我们看到了规模效应的经济性:因为一个供应商正在运行数千个非常类似的数据库，所以你为托管数据库支付的费用较低，。
降低的成本给你带来的收益来自两个方面：第一个是基础设施成本收益，它纯粹来自于与他人共享基础设施(如硬件、网络)；第二个是人工成本收益，你可以花更少的时间在外包的无服务器系统上，而不是花在自己开发和托管的同等系统上。
但是，这种好处与你从基础设施服务(IaaS)或平台服务(PaaS)中获得的好处并没有太大的不同。但是可以通过无服务器架构的BaaS和FaaS来扩展这一优势。
IaaS和PaaS的前提是服务器和操作系统管理可以商品化，而BaaS则是整个应用程序组件商品化的结果。
身份验证就是一个很好的例子。许多应用程序编写自己的身份验证功能，这些功能通常包括注册、登录、密码管理和与其他身份验证提供者的集成等功能。总的来说，这种逻辑在大多数应用程序中都非常相似，像Auth0这样的服务已经被创建，它允许我们将已经构建好的身份验证功能集成到应用程序中，而无需我们自己开发它。
BaaS数据库也是同样道理，比如Firebase的数据库服务。一些移动应用程序团队发现，让客户端直接与服务器端数据库通信是有意义的。BaaS数据库删除了大量的数据库管理开销，并且提供了对不同类型的用户执行适当授权的机制，这与无服务器应用程序的模式相同。
根据你的实际情况，这些想法可能会让你感到不安(我们将在缺陷一节中讨论)，但不可否认的是，许多成功的公司几乎不用自己的服务器端代码就能生产出令人信服的产品。
无服务器FaaS的乐趣之一是——正如我在本文前面提到的——“水平缩放是完全自动的、有弹性的，并且由服务商管理。”最大的好处是，只需要为你需要的计算付钱。如在AWS Lambda中，取决于应用形态，可能只需要支付100毫秒的边，界对你而言这很划算。
假设你正在运行一个服务器应用程序，该应用程序每分钟只处理一个请求，处理每个请求需要50毫秒，则你在一个小时内的平均CPU使用率是0.1%。如果这个应用程序部署到自己的专用主机上，那么这是非常低效的。上千个类似的应用程序都可以共享一台机器。
无服务器FaaS解决了这种低效率，以更低的成本为你提供好处。在上面的示例应用程序中，你只需要为每分钟所花费的100毫秒计算时间付钱，这是总时间的0.15%。
这带来了下面的连锁效应：
让我们看另一个例子。假设你的流量配置文件非常繁忙——可能你的基本流量是每秒20个请求，但是每5分钟你就会在10秒钟内接收到每秒200个请求(是通常数量的10倍)。如果你不想希望在流量峰值阶段减少响应时间，怎么解决这个问题？
在传统环境中，你可能需要将硬件总数增加10倍，以处理峰值，即使峰值的总持续时间占总机器正常运行时间的不到4%。在这里，自动缩放可能不是一个好的选择，因为在新实例启动时，服务器的新实例需要较长的启动时间。
然而对于无服务器FaaS，这就不是一个问题。如果你的流量分布是均匀的，那么你就不会有什么不同，你仅需要支付高峰期产生的额外计算能力。
显然，我在这里特意选择了几个例子，其中无服务器FaaS可以节省大量的成本。但重点是想说明，从缩放的角度来看，除非你有一个非常稳定的流量形态，并且始终充分利用你的服务器主机的全部能力，否则使用FaaS可以节省成本。
关于FaaS成本还有一个更有趣的方面:对代码进行性能优化不仅会提高应用程序的速度，而且还会直接降低运营成本，具体降低多少取决于供应商的收费的粒度。例如，假设一个应用程序最初需要一秒钟来处理一个事件。如果通过代码优化，这将减少到200ms，它(在AWS Lambda上)将立即看到在不更改任何基础设施的情况下，计算成本节省了80%。
在无服务器BaaS方面，很容易理解为什么操作管理比其他体系结构更简单:支持更少的组件就等于更少的工作。
尽管上一节中我们对缩放记忆犹新，但值得注意的是，FaaS的缩放功能不仅降低了计算成本，还减少了操作管理，因为缩放是自动的。
如果你的缩放过程是手动的(例如，需要人为地向服务器数组添加和删除实例)，那么使用FaaS你可以很高兴地忽略这一点，并让FaaS供应商为你扩展应用程序。
即使你已经达到在非FaaS体系结构中使用自动缩放的程度，仍然需要安装和维护。而FaaS不再需要这项工作。
与部署整个服务器相比，打包和部署FaaS功能很简单。你所做的就是将所有代码打包成一个zip文件，然后上载它。没有Puppet/Chef，没有启动/停止shell脚本，没有是否在机器上部署一个或多个容器的决定。如果你刚刚起步，那么你甚至不需要打包任何东西——甚至可以在服务提供者的控制台上编写代码(显然，这并不推荐!)。
这个过程不需要很长时间来描述，但是对于一些团队来说，这个好处可能是绝对巨大的:一个完全无服务器的解决方案需要零系统管理。
PaaS解决方案具有类似的部署优势，但正如我们前面看到的，在比较PaaS和FaaS时，FaaS在伸缩性方面具有优势。
更简单的运营管理是我们工程师所理解的好处，但这对我们的业务意味着什么呢?
显而易见的是成本:花费在操作上的时间越少，操作所需的人员就越少，正如已经描述的那样。但在我看来，更重要的是上线时间。随着我们的团队和产品越来越倾向于精益和敏捷流程，我们希望不断尝试新事物并快速更新现有系统。虽然在持续交付的环境中进行简单的重新部署可以快速迭代稳定的项目，但是拥有“快速部署”的能力允许我们尝试平滑和低成本的新实验。
虽然成本效益是无服务器架构最容易显现的改进，但上线时间的提前让我最兴奋。它可以使产品开发的思维模式持续不断地试验，这才是对软件交付的真正革命。
在过去的几十年里，世界上数据中心的数量和规模都有了巨大的增长。使用物理资源来构建这些中心,相关的能源需求是如此之大，这会造成巨大的环境影响。
一方面，云基础设施可能已经帮助减少了这种影响，因为公司只能在绝对需要的时候“购买”更多的服务器，而不是提前很长时间提供所有可能需要的服务器。不过，也有人可能会说，如果很多服务器没有进行足够的容量管理，那么供应服务器的便捷性可能会让情况变得更糟。
无论我们使用的是自托管服务器、IaaS、还是PaaS基础架构解决方案，我们仍然需要手工决策应用程序的容量，这些决策通常要持续数月或数年。通常，我们对管理能力持谨慎态度，这是正确的，但这导致过度供应，导致低效。使用无服务器的方法，不再自己计算容量——让无服务器供应商提供的计算能力刚好满足实时需求。供应商可以综合他的客户的共同需求做出容量计算。
这种差异将提升跨数据中心的资源使用效率，因此与传统的容量管理方法相比，可以减少环境影响。
对于任何外包策略，都是将一些系统控制权交给第三方供应商。这种缺乏控制可能表现为系统停机、意外限制、成本更改、功能丢失、强制API升级等等。
多租户指多个不同客户(或租户)的软件实例在同一台机器上运行，且可能在同一托管应用程序中运行的情况，这是实现规模经济效益的策略。服务供应商尽其所能让客户觉得他们是唯一使用他们系统的人，而通常优秀的服务供应商在这方面做得很好。但是，没有一个完美的多租户解决方案，有时会在安全性(一个客户能够看到另一个客户的数据)、健壮性(一个客户的软件中的错误导致另一个客户的软件出现故障)和性能(一个高负载的客户导致另一个客户的速度变慢)方面存在问题。
这些问题并非无服务器系统独有——它们存在于使用多租户的许多其他服务产品中。AWS Lambda现在已经足够成熟，我们不希望看到它出现此类问题，但是你应该注意任何不太成熟服务(无论是来自AWS还是其他供应商)的此类问题。
你从一个供应商拿到的任何无服务器特性都很可能由另一个供应商以不同方式实现。如果你想换供应商几乎肯定需要更新你的操作工具(部署、监控、等等),可能需要改变代码(例如,以满足不同的 FaaS 接口),甚至可能需要改变设计或架构。
即使能够轻松地迁移生态系统的一部分，你也可能会受到另一个体系结构组件的更大影响。假设你正在使用AWS Lambda来响应AWS Kinesis消息总线上的事件，尽管AWS Lambda、谷歌云功能和Microsoft Azure功能之间的差异可能相对较小，但仍然无法将后两个供应商实现直接连接到AWS的Kinesis流。这意味着，如果不迁移基础设施的其它部分，就不可能将代码从一个解决方案迁移到另一个解决方案。
很多人都被这个想法吓到了——如果今天选择的云供应商明天需要更改，还需要做很多工作，那么的确体验很差。因此，一些人采用“多云”方法，开发和操作应用程序的方式与实际使用的云供应商无关，但这通常比单云方法成本更高——因此，虽然供应商绑定是一个合理的问题，但我仍然建议选择一个你满意的供应商，并尽可能地利用它们的功能。
采用无服务器方法会面临大量安全问题。这里有一些需要考虑的事情：
使用“完整的”BaaS体系结构，服务器端不编写自定义逻辑——全部在客户机中编写。这对于你的第一个客户端平台来说可能很好，但是一旦你需要换一个平台，你就需要重复实现该逻辑的一个子集，但在更传统的体系结构中你不需要这样的重复工作。例如，如果在这种系统中使用BaaS数据库，那么你的所有客户机应用程序(可能是web、原生iOS和原生Android)现在都需要能够与供应商数据库通信，并且需要了解如何从数据库模式映射到应用程序逻辑。
有了完整的BaaS体系结构，就没有机会为优化服务器设计了。“后端到前端”模式的存在是为了在服务器中抽象出整个系统的某些底层知识，在某种程度上是为了让客户端在移动应用程序中能够更快地执行操作，并使用更少的电池电量。这种模式不适用于完整的BaaS。
对于完整的BaaS体系结构，存在另一缺点：在这种体系结构中，所有定制逻辑都位于客户机中，并且只提供供应商提供的后端服务。缓解这两种情况的一种方法是采用FaaS或其他类型的轻量级服务器端模式，并将某些逻辑转移到服务器。
之前说过：“当涉及到本地时，FaaS函数有很大的限制。状态。. .你不应该假定一个函数的一次调用的状态对同一函数的另一次调用是可用的。”。
这种假设的原因是：对于FaaS，我们通常无法控制函数的主机容器何时启动和停止。
那么，如果不能将状态保存在内存中，FaaS的状态会如何变化呢?在许多情况下，使用快速NoSql数据库、进程外缓存(例如redis)或外部对象/文件存储(例如S3)获取是一些选项。但是这些都比内存或机器上的持久性慢得多。你需要考虑应用程序是否适合这种情况。
这方面的另一个问题是内存缓存。许多从外部存储的大数据集读取数据的应用程序会在内存中保留部分数据集的缓存。你可能正在从数据库中的“引用数据”表读取数据，并使用Ehcache之类的东西。或者，也可以从指定缓存头的HTTP服务中读取，在这种情况下，内存中的HTTP客户机可以提供本地缓存。
FaaS确实允许使用一些本地缓存，如果你的函数使用得足够频繁，这可能是有用的。例如，对于AWS Lambda，我们通常希望一个函数实例能够存在几个小时，每隔几分钟至少使用一次。这意味着可以使用Lambda提供的(可配置的)3gb RAM，或512mb本地“/tmp”空间，对于某些缓存，可能足够了。否则，不再需要假定进程内缓存，并且需要使用Redis或Memcached之类的低延迟外部缓存。然而，这需要额外的工作，可能会非常慢。
前面描述的缺点可能总是存在于无服务器环境中。这些问题的解决方案在改进，但毕竟是存在的。
剩下的缺点完全归结为目前的技术水平。随着供应商和/或英雄社区的意愿和投资，这些都可以被消灭。事实上，自本文的第一个版本以来，这个列表已经缩小了。
在我编写本文的第一个版本时，AWS很少提供Lambda函数的配置方式。这个问题现在已经得到了解决，但是如果你使用的是一个不太成熟的平台，那么它仍然是值得检查的。
下面的例子，说明为什么在处理FaaS时，“购者自慎”是一个关键短语。AWS Lambda限制在给定时间内可以运行的Lambda函数的并发执行次数。这个极限是1000;这意味着你可以在任何时候执行一千个函数实例。如果你需要超过这个标准，可能会遇到异常、排队和/或一般的慢下来。
这里的问题是：这个限制是跨整个AWS帐户的。一些组织使用相同的AWS帐户进行生产和测试。这意味着，如果你组织中的某地某人执行了一种新的负载测试，并开始尝试执行1000个并发Lambda函数，将意外地关闭你的生产应用程序。
即使使用不同的AWS帐户进行生产和开发，一个过载的产品lambda(例如，处理来自客户的批处理上传)也可能导致独立的受lambda支持的实时生产API变得无响应。
Amazon在这里通过保留并发性提供了一些保护。保留并发性允许你限制Lambda函数的并发性，这样它就不会破坏你帐户的其他部分，同时确保无论帐户中的其他函数在做什么，始终有可用的容量。但是，默认情况下不会为帐户打开预留并发，因此需要小心管理。
在本文前面我提到，如果AWS Lambda函数运行时间超过5分钟，则会中止它们。这两年来一直是这样的，AWS也没有表现出任何想要改变的迹象。
我之前谈到了冷启动，并提到了关于这个主题的文章。随着时间的推移，AWS已经改进了这一领域，但是仍然存在一些重大问题，特别是对于偶尔触发的jvm实现函数和/或需要访问VPC资源的函数。期待这方面将继续改进。
好了，这已经足够去选择AWS了。我相信其他供应商也有一些问题。
单元测试无服务器应用程序非常简单，原因我在前面已经讨论过:编写的任何代码都“只是代码”，而且在大多数情况下，不必使用一大堆定制库或必须实现的接口。
而另一方面，集成测试无服务器的应用程序是困难的。在BaaS世界中，你依赖外部提供的系统，而不是(例如)自己的数据库。那么，集成测试也应该使用外部系统吗?如果是，那么这些系统对测试场景有多大的适应性?你能轻易的丢弃状态吗?你的供应商能否为负载测试提供不同的计费策略?
如果你想为集成测试打桩那些外部系统，供应商是否提供打桩模拟?如果是，桩的保真度如何?如果供应商不提供桩，你自己将如何实现打桩?
同样的问题也存在于FaaS领域，尽管这一领域已经有所改善。现在可以在本地为Lambda和Microsoft Azure运行FaaS函数。然而，没有一个本地环境可以完全模拟云环境;我不建议完全依赖本地FaaS环境。事实上，我还想更进一步，建议你运行自动化集成测试的规范环境(至少作为部署管道的一部分)应该是云，并且你应该主要将本地测试环境用于交互式开发和调试。这些本地测试环境不断改进。
还记得我在前几节提到的在云中运行集成测试时的跨帐户执行限制吗?你可能希望至少将这些测试与你的生产云帐户隔离。
考虑集成测试重要原因是，我们使用无服务器FaaS与其他架构相比，每个功能都要小得多，因此我们比与其他架构风格相比，更依赖集成测试。
依赖基于云的测试环境，而不是在笔记本电脑上本地运行所有东西，这对我来说是一个相当大的冲击。但时代在变，我们从云计算中获得的能力与谷歌等公司的工程师们十多年来所拥有的类似。Amazon现在甚至允许你在云中运行IDE。我还没有完全做到这一点——但它可能会到来。
使用FaaS进行调试是一个有趣的领域。这里已经取得了一些进展，主要与本地运行FaaS函数有关。Microsoft为本地运行但由远程事件触发的函数提供了出色的调试支持。Amazon也提供类似的服务，但还没有由生产事件触发的机制。
调试在云生产环境中实际运行的函数是另一回事，Lambda至少还不支持这种功能，不过如果能看到这种功能就太好了。
这是一个正在积极改进的领域。AWS在改进这方面已经取得了巨大的进步，稍后我将在“无服务器架构的未来”一节中进一步讨论它。
“发现”是微服务世界中经常讨论的主题:它是一个服务如何调用另一个服务的正确版本的问题。在无服务器的世界中，很少有关于发现的讨论。起初这让我担心，但现在我不那么担心了。许多无服务器的使用本质上是事件驱动的，在这里事件的使用者在某种程度上通常是自注册的。对于面向API的FaaS用法，我们通常在API网关后面使用它们。在这种情况下，我们在API网关前面使用DNS，在网关后面使用自动部署/流量转移。甚至可以在API网关前面使用更多的层(例如，使用AWS CloudFront)来支持跨区域弹性调度。
由于容器的短暂性，对FaaS来说，监控是一个棘手的领域。大多数云供应商都提供了一定数量的监控支持，我们也看到了许多来自传统监控厂商的第三方工作。不过，他们和你最终能做什么取决于供应商提供给你的基本数据。在某些情况下，这可能是好的，但是对于AWS Lambda，至少，它是非常基础的。在这个领域，我们真正需要的是开放api和第三方服务提供更多的帮助能力。
ThoughtWorks在其技术雷达出版物的一部分中，讨论了过于强势的API网关。虽然该链接一般指的是API网关(例如，对于那些传统部署的微服务前端)，但它肯定可以作为HTTP前端到FaaS函数的API网关使用。问题是API网关提供了许多特定于应用程序的逻辑。这种逻辑通常很难测试、版本控制，有时还很难定义。通常，这种逻辑最好像应用程序的其他部分一样保留在程序代码中。
如果我们将API网关视为BaaS，那么考虑它提供给我们的所有选项是否有价值，以便节省我们的工作。如果为每个请求使用API网关付费，而不是按CPU利用率付费，那么最大化地使用API网关的功能不是更划算吗?
我的建议是明智地使用增强的API网关功能，并且只在它确实能够长期节省工作时才这样做。绝对不要使用不能在源代码可控的配置文件或部署脚本中表达的API网关特性。
在前面提到过，无服务器并不是“无运维”——从监控、体系结构伸缩、安全性和网络的角度来看，还有很多工作要做。然而，在开始时很容易忽略这一点。这里的危险正在被一种虚假的安全感所迷惑。也许你已经启动并运行了你的应用程序，但它却意外地出现在了***新闻上，突然间你需要处理的流量是原来的10倍，哎呀!你一下懵逼了。
解决办法是培训。使用无服务器系统的团队需要尽早考虑运维活动，供应商和社区应该提供教学帮助他们理解这意味着什么。
我们即将结束对无服务器架构世界的探索。最后，我将讨论我认为无服务器世界可能在未来几个月和几年发展的几个领域。
无服务器仍然是一个相当新的世界。因此，上一节关于缺点的内容非常广泛，甚至没有涵盖我所能想到的所有内容。无服务器的最重要发展将是减少固有的缺陷，并消除或改进实施缺陷。
工具仍然是无服务器的一个问题，这是因为许多技术和技术都是新的。部署/应用程序绑定和配置在过去两年中都得到了改进，其中无服务器框架和Amazon的无服务器应用程序模型处于领先地位。尽管亚马逊和谷歌可以向微软和Auth0寻求更多的灵感，但“前10分钟”的体验并没有想象中那么神奇。
我很高兴看到云供应商积极解决的一个领域是更高级别的发布方法。在传统系统中，团队通常需要编写自己的流程来处理蓝绿部署和canary发布等“流量转移”思想。考虑到这一点，Amazon支持Lambda和API网关的自动流量转移。在无服务器的系统中，这样的概念更有用，因为一次100个Lambda函数的系统原子版本构成了许多单独部署的组件。事实上，Nat Pryce向我描述了一种“混合台”的方法，在这种方法中，我们可以在一个业务流中逐渐将一组组件引入和退出。
分布式监控可能是最需要改进的领域。我们已经从Amazon的 X-Ray和各种第三方产品中看到了早期的工作，但是这绝对不是一个已经解决的问题。远程调试也是我希望看到更广泛应用的东西。Microsoft Azure函数支持这一点，但Lambda不支持。能够在远程运行的函数打断点是一种非常强大的功能。
最后,我希望看到改善的工具更有效地“元操作”——管理成百上千的FaaS功能,配置服务等。
对于许多应用程序来说，FaaS缺乏持久的服务器状态是可以接受的，但是对于许多其他应用程序来说，这是一个致命的问题——无论是对于大型缓存集还是对会话状态的快速访问。
对于高吞吐量应用程序，一个解决方案可能是供应商在事件之间让函数实例存活更长一点，并使用常规的进程内缓存方法。由于缓存不会对每个事件都是热的，所以这种方法不是100%有效的。对于使用传统部署的自动伸缩应用程序来说，也存在同样的问题。
更好的解决方案是非常低延迟地访问进程外数据，比如能够以非常低的网络开销查询Redis数据库。考虑到Amazon已经在他们的Elasticache产品中提供了一个托管的Redis解决方案，而且他们已经允许使用放置组对EC2(服务器)实例进行相对定位，这看起来并不过分。
但是，更有可能的是，我认为我们将看到不同种类的混合(无服务器和非服务器)应用程序架构被采用，以考虑状态外部化约束。以低延迟应用程序为例,你可能会看到一个常用方法：常驻服务器处理一个初始请求,收集所有必要的上下文来处理该请求的本地和外部状态, 然后将一个完全上下文化的请求传递给FaaS函数群,而不需要去外部查找数据。
目前无服务器FaaS的某些缺点归结为平台的实现方式。执行持续时间、启动延迟和跨功能限制是三个明显的缺陷。这些问题可能会通过新的解决方案得到解决，也可能会有增加额外成本的变通办法。例如，我认为可以通过允许客户总是在低延迟情况下请求一个FaaS函数的两个实例，用来减少启动延迟，当然客户需要为此支付费用。Microsoft Azure的功能具有这种理念的元素，它具有持久的功能，以及应用程序服务计划托管的功能。
当然，我们将看到平台的改进，而不仅仅是修复当前的缺陷，这些改进也将令人兴奋。
通过培训，许多特定于供应商的无服务器固有缺陷正在得到缓解。让一个或多个应用程序供应商托管这么多生态系统意味着什么？每个使用此类平台的人都需要积极思考。我们需要考虑这样的问题，我们是否需要考虑“设计来自不同供应商的并行解决方案，以防其中一个不可用”和“在部分停机的情况下，应用程序如何优雅地降级?”这样的问题。
培训的另一个领域是技术操作。许多团队现在的系统管理员比以前少了，而无服务器架构将加速这一变化。但是系统管理员不只是配置Unix盒和Chef脚本—他们通常是支持、网络、安全等方面的前线人员。
在一个无服务器的世界中，真正的DevOps文化变得更加重要，因为那些非系统管理员活动仍然需要完成，而且现在通常是开发人员对它们负责。对于许多开发人员和技术领导来说，这些活动可能并不自然，因此培训和与操作人员的密切协作是重要的。
最后，关于如何缓解缺陷问题:供应商必须更加明确我们对他们平台的期望，因为我们更多地依赖他们提供托管功能。虽然迁移平台是困难的，但这并非不可能，不值得信任的供应商将看到他们的客户将业务转移到别处。
我们对如何以及何时使用无服务器架构的理解还处于初级阶段。现在，团队正在把各种各样的想法扔到无服务器的平台上，看看哪些是有用的。感谢拓荒者!我们开始看到推荐实践模式的出现，而这些知识只会越来越多。
我们看到的一些在应用程序体系结构中模式：例如，在FaaS函数变得笨拙之前，它们可以变得多大?假设我们能够自动地部署一组FaaS函数，那么创建这些组的好方法是什么?它们是否与我们当前将逻辑聚合到微服务中的方式密切相关，或者架构上的差异是否将我们推向了一个不同的方向?
在无服务器应用程序体系结构中，一个特别有趣的活跃讨论领域是它如何与事件思维交互。AWS Lambda的产品主管Ajay Nair在2017年对此做了一次精彩的演讲，这也是CNCF无服务器工作组讨论的主要领域之一。
更进一步，在FaaS和传统的“始终在线”持久服务器组件之间创建混合架构的好方法是什么?什么是将BaaS引入现有生态系统的好方法?相反，BaaS系统需要开始接受或使用更多自定义服务端代码的警告信号是什么?
我们还看到讨论了更多的使用模式：FaaS的一个标准示例是媒体转换，例如，每当将大型媒体文件存储到S3存储桶中时，就会自动运行一个进程，在另一个存储桶中创建较小的版本。然而，我们现在也看到无服务器在数据处理管道、高度可伸缩的web api以及在操作中作为通用“粘合剂”代码方面的重大应用。其中一些模式可以作为通用组件实现，直接部署到组织中;我曾经写过关于Amazon的无服务器应用程序存储库的文章，它是这种思想的早期形式。
最后，随着工具的改进，我们开始看到推荐的操作模式。我们如何合理地为FaaS、BaaS和传统服务器的混合架构聚合日志记录?如何最有效地调试FaaS函数?这些问题的许多答案——以及正在出现的模式——都来自云供应商本身，我预计这一领域的活动将会增长。
在宠物店的例子中,我们看到早些时候我给一个宠物店服务器分成几个服务器端组件和一些逻辑转移到客户端,。但从根本上说，这仍然是一个以客户端为中心的架构,并且远程服务在已知位置。
我们现在开始在无服务器世界中看到的是模糊的责任分配。一个例子是Amazon的Lambda@Edge产品:一种在Amazon CloudFront内容交付网络中运行Lambda函数的方法。有了Lambda@Edge, Lambda函数就可以在全球范围内分布——一个工程师的一次上传活动就意味着该函数将被部署到全球100多个数据中心。
此外，Lambda函数可以在设备上运行，机器学习模型可以在移动客户端上运行，在你了解它之前，“客户端”和“服务器端”的分叉似乎不再有意义。无服务器将变得无区域。
到目前为止，我所看到的FaaS的大多数用法都是将现有的代码和设计思想“FaaSification”(FaaS化):将它们转换为一组无状态函数。这非常强大，但我希望我们将开始看到更多的抽象，可能还有语言，使用FaaS作为底层实现，让开发人员受益于FaaS，而不需要将其应用程序看作一组离散函数。
例如，我不知道谷歌的Dataflow产品是否使用FaaS实现，但我可以想象有人创建了一个产品或开源项目，做类似的事情，并使用FaaS作为实现。这里的比较类似于Apache Spark。Spark是一个用于大规模数据处理的工具，它提供了非常高级的抽象，可以使用Amazon EMR和Hadoop作为其底层平台。
我认为在无服务器系统的集成和验收测试方面还有很多工作要做，但是很多工作与以更传统方式开发的“云原生”微服务系统相同。
一个基本思想是在生产和监控驱动的开发中采用这样的测试思想：一旦代码通过了基本的单元测试验证，就可以将其部署到一个业务子集，并与上一个版本比较。这可以与我前面提到的业务转移工具相结合。这并不适用于所有的上下文，但是对于许多团队来说，是一个非常有效的工具。
团队可以通过几种方式使用无服务器，同时减少对特定云供应商的依赖。
无服务器框架的存在主要是为了简化无服务器应用程序的运维任务，但也提供了关于在何处以及如何部署此类应用程序的余地。例如，如果能够根据每个平台的运维能力轻松在AWS API网关+ Lambda和Auth0 webtask之间切换(即使是现在)，那将是非常棒的。
其中一个棘手的方面是对抽象FaaS编码接口建模，目前没有标准化的指导，但是这正是关于CloudEvents的CNCF无服务器工作组的工作。
但是，一旦运维的复杂性浮出水面，为多个平台提供抽象部署有多少价值就值得怀疑了。例如，在一个云中获得正确的安全性在另一个云中可能是不同的。
建议我们在不使用第三方提供商的情况下使用无服务器技术，这听起来可能有些奇怪，但请考虑以下想法:
现在已经有了一个相当大的无服务器社区，它有多个会议、许多城市的聚会和各种在线群组。我预计这一趋势还会继续发展，可能会像Docker和Spring这样的社区一样。
尽管名称令人困惑，但无服务器是一种体系结构风格，在这种体系结构中，我们将自己的服务器端系统作为应用程序的一部分运行。通过两种技术实现这一点:BaaS和FaaS，前者将第三方远程应用程序服务紧密集成到应用程序的前端，后者将服务器端代码从长时间运行的组件移动到短暂的函数实例。
无服务器并不是解决每个问题的正确方法，所以要小心那些说它将取代你所有现有架构的人。如果你现在尝试使用无服务器系统，请小心，特别是在FaaS领域。虽然有丰富的(可伸缩的和节省的部署工作)资源可以利用，但也有调试和监视的问题潜伏在角落中。
但是，这些财富不应该很快就被抛弃，因为无服务器架构有许多积极的方面，包括降低操作和开发成本、更容易的操作管理和减少环境影响。但我认为最重要的好处是减少了创建新应用程序组件的反馈循环。我是“精益”方法的超级粉丝，主要是因为我认为将技术尽快呈现给终端用户以获得早期反馈是很有价值的，而无服务器产品上市时间的缩短正好符合这一理念。
如今(2018年5月)，无服务器服务以及我们对它们的理解正处于“略显笨拙的青春期”。在未来的几年里，这个领域将会有很多的进步，看看无服务器如何适应我们的架构工具集将是一件很有趣的事情。