AWS Lambda赢得了胜利，但首先它不得不消亡

重大功能更改已成功将Lambda工作负载推向主流，即使FaaS纯粹主义者感到背叛

如果您问AWS，他们肯定会说。今年，在亚马逊内部构建的所有新应用程序中，几乎有一半在Lambda上运行。安迪·贾西（Andy Jassy）在他的re：Invent主题演讲中花了一些时间，召集了成千上万现在在生产中运行Lambda工作负载的企业，但也许最有趣的是，今年新的无服务器功能公告逐渐转变为贾西（Jassy）的主题演讲-通常是最华丽的地方，是一年中最具战略意义的内容。至少，AWS明确认为无服务器现在是其云的主要卖点之一。

（另一方面，有一篇很奇怪的文章，它的大部分时间都在说明FaaS的增长，但是却以“无服务器采用失速”为标题，因为…Kubernetes团队说他们没有使用太多的Lambda？报告少吃蔬菜。）

没有争议的是，Lambda仍然是FaaS的重达900磅的大猩猩，今天看起来与2015年发布GA时大不相同。大声，怪异的利基市场的工程师们早早地购买了无服务器，他们对什么有一个非常具体的想法好的无服务器系统看起来像……最近，Lambda一直在推敲自己的假设。

最初的FaaS纯度理想并不仅仅是凭空实现的。就在2016年，AWS无服务器领导层开始谈论他们称之为“无服务器计算宣言”的事情。这是功能即服务应如何运作的根本愿景。宣言出现在各种演讲中，包括ACG的ServerlessConf。以下是其主要宗旨：

该宣言为如何构建和部署软件形成了令人震惊且高度反文化的蓝图。它吸引了一个规模很小但生机勃勃的真正信徒团体，以及一些更大更响亮的怀疑论者。

但是回想起来，无服务器计算宣言很难渗透到那个小的，参与的核心。大胆的愿景只是遗漏了太多的现有遗留工作负载和团队。

因此，逐渐地，就像奥威尔（Orwell）的动物农场中的诫命一样，AWS的无服务器无协议计算的不可商议性开始发生变化。让我们遍历宣言的每个要点，看看Lambda是否仍然遵守宣言。

Sorta，但不严格。您可以部署多功能Lambda层来管理大型二进制文件，也可以（现在处于预览状态）部署Lambda Extensions来插入第三方代理，我听说这绝对不应该被视为“ Lambda的辅助工具”。

不再如此。从re：Invent 2020开始，Lambda现在允许您带上自己的容器，而不仅仅是运送ZIP文件。

不必要。 Lambda现在与EFS集成，从技术上讲，我认为它是“在其他地方”，但是与附加到服务器的任何其他NFS共享相比，“在其他地方”没有更多。这是安装在您的计算机上的持久文件系统。

是!现在Lambda可以运行容器了，我认为请求模型现在是Lambda与托管容器服务（例如AWS Fargate）之间最大的概念差异。 Lambda为每个并发请求提供了一个新的执行环境，而类似Fargate的服务仍将在同一个（长期存在的）容器上处理多个并发请求。

不再如此。满足预置容量，它将您的冷启动问题换成热成本问题。 （我偷偷摸摸，但“预配置容量”比运行自己的Lambda预热作业好很多，以前很多人都这样做。）

恩这是关于抽象出可用区，除了Lambda（包括Fargate！）之外，现在还有许多更高级别的AWS服务。就是说，我们开始从AWS那里听到更多的指导，实际上，您需要考虑的故障域是区域。没错：区域是新的可用区域，而精明的Lambda开发人员正在推出他们自己的（非常不受管理的）多区域架构。

为了加强趋势，让我们检查一下Lambda的其他两个定义性早期功能：

越来越少的真实。在过去的5年中，功能磁盘的大小，运行时限制以及CPU和内存的大小稳步增长。今天，您可以使用10 GB内存和6个vCPU在Lambda函数上运行15分钟，这是一个足够大的计算量，足以使您认真考虑多线程，多用途函数以及其他与之相反的理想做法。 FaaS。

只要你想要。在过去，Lambda体系结构严重偏向于IAM安全性，而不是使用VPC，部分原因是出于意识形态原因，而且还因为将功能附加到自定义ENI上增加了巨大的冷启动开销。如今，AWS的创新使客户管理的VPC与Lambda更加兼容。

巧克力工厂之旅结束时，我感觉像威利·旺卡（Willy Wonka），环顾四周，看看所有孩子们都去了哪里。在所有这些意识形态原则中，每条要求的缩放比例都是唯一的问题。

当然，您仍然可以根据原始的无服务器宣言进行构建。但是该服务不需要您。

如果您不得不将Lambda的修订后的价值支柱精炼成动物农场风格的单一格言，那么您现在会说什么？ “所有工作负载都得到管理，但是有些工作负载比其他工作负载更受管理？”

现在似乎是时候来说明我最喜欢Lambda的新增功能了。我认为它们是必要的，并且在许多情况下是不可混和的商品。

四年前我不会这么说。那时我更像是FaaS纯粹主义者。让我改变主意的是，多年以来，听到了工程团队的非常特殊的陈述，并以不同的形式反复出现：

我想使用Lambda，如果可以的话……[连接回我的本地VPC，足以应付我的工作量，让我使用与其他系统相同的语言或开发人员工具，一直很热情，支持某种形式共享存储等）

我对这些陈述的第一个反应是：如果无法或不支持无状态，无容器，从零缩放到零的函数，为什么要使用Lambda？这就是Lambda的重点。在我看来，这就像来自《 New Stack》调查中的那些Kubernetes猫，说如果它们只含有更多的肉，它们真的很想吃蔬菜。

但自那以后，我开始理解该声明的真正强大部分是开始部分。这是渴望的声明。

Lambda和一般的无服务器计算到底是什么激发了这么多人的反应？为什么从小型初创公司到大型OL传统企业，全新的婴儿计算范式都会引起如此强烈的兴趣？

因为无处不在，所以无服务器计算是一个主意。用一个简单的词组表达一个想法：少拥有，多建设。所有无服务器的学说，所有技术指导都可以归结为这一目标。 Lambda是一种理想的生活方式。

大约在2016年的Lambda大大领先于它的时代，并且在某种程度上仍然如此。但是，由于增加了新功能（包括容器支持，包括容器支持），因此与以往相比，它使自己的东西更少，构建更多的身份对于更多的构建者更易于访问。

AWS正在做的是一个接一个地删除if onlys。他们通过为需要它们的团队提供令人放心的选项（共享存储，已配置的容量）来消除对无服务器的反感。我很想使用Lambda！

某些团队是否会出于混乱或惯性使用这些功能，而没有意识到他们可以构建更激进，更像宣言的东西？是的，我认为这是AWS可以提供​​更多帮助的领域。

看起来，Lambda控制台是一团糟–您知道，我知道，AWS也知道。与2001年的VCR相比，它具有更完善的功能蠕变和不连贯的UX路径。并说出您对基础架构即代码的看法，控制台仍然是人们探索新服务的方式。他们如何对自己想要成为什么样的建筑商产生感觉。

当然，需要重新设计控制台，而不仅仅是重新设计。我们需要一个能够支持原始宣言的Lambda功能的应用程序：代码级编程抽象，功能级部署。然后，在您突破宣言的限制或您自己的组织约束条件时，仔细揭示渐进式复杂性。 （是否存在“递归复杂性”之类的东西？因为这是当前的控制台。）

您想要的是使构建者在每次开始新项目时都要面对更简单，更受管理的选项。随着时间的流逝，这会改变人们的看法。它不断以“无服务器方式”向他们展示：嘿，我可以使用事件来构建它！我不需要将此功能放在VPC中！默认值很重要。我期待看到AWS如何在这里继续指导其客户取得成功。

同时，Lambda最终获得了认真的采用，最终赢得了胜利，因为它摆脱了标志着其早期发展的FaaS纯粹主义-在不损害其真正价值的前提下，逐渐减少拥有自己的东西，建立更多的东西。无服务器计算宣言必须消亡，这样无服务器的承诺才能最终实现。