#108: Lambda on Rust with James Eastham
01:02:02 Share

感谢 Hookdeck 赞助本期节目。如果您想提升您的事件驱动架构，请查看他们的无服务器事件网关 hookdeck.com/theburningmonk，并帮助支持本频道。James Eastham 是 Datadog 的开发者布道师，也是“在 Rust 中编写 Lambda 函数”一书的合著者。在本期节目中，我们深入探讨了在 Rust 中编写 Lambda 函数以及为什么您应该学习 Rust。 节目链接： NSA 关于内存安全的报告 Julian Wood 在 re:Invent 2022 上关于 Lambda 内部机制的演讲 James 的 YouTube 频道 在 Rust 中编写 Lambda 函数 第 106 期关于 middy 与 Luciano Mammino 的对话 第 97 期关于 LLRT（Lambda 的超高速 JavaScript 运行时） 开场主题曲： 凯文·麦克劳德的《快乐星期一》 链接：https://incompetech.filmmusic.io/song/3495-cheery-monday 许可证：http://creativecommons.org/licenses/by/4.</context> <raw_text>0 本期节目由 HookDeck 赞助。使用这个完全无服务器的事件网关来提升您的事件驱动架构。要了解更多信息，请访问 hookdeck.com/theburningmonk。

大家好，欢迎回到另一期《真实世界的无服务器》节目。今天我们邀请到了 James Isham，他最近离开了 AWS，加入 Datadog 担任开发者布道师。James，很高兴邀请你来到节目。你好 Jan，感谢邀请我。这是一种荣幸，实际上。我一直是节目的忠实听众，第一次打电话。我觉得我最近说了很多次这句话。所以是的，我很高兴来到这里。

是的，我在社交媒体上看到了很多你的帖子。你写了很多关于用 Rust 编写 Lambda 函数的文章，最近也和你的合著者一起参加了节目。我们更多地谈到了 Luciano，更多地谈到了 MIDI，但也触及了 Rust。你实际上一直在分享很多关于用 Rust 编写 Lambda 函数的内容。

在我们开始之前，你想花一点时间向我们介绍一下你加入 AWS 和无服务器的历程以及你一直在做的工作吗？是的，当然。我实际上是自学成才进入科技行业的。我在英国完成了大学学业，也就是到 18 岁。我不知道这在美国相当于什么。

我不知道自己想做什么。所以我最终去了一家软件公司做一线支持工作。他们构建了一个电子商务后端，全部使用 .NET 和 SQL Server。然后我想，如果我自学 SQL Server，我可以更好地支持人们。所以我自学了 SQL Server。然后我自学了 .NET。然后我慢慢地从那里向上发展。

我来自 .NET 背景，所以 Rust 是一种有趣的语言，我们或许可以讨论一下它们之间的区别，因为它们既相似又非常不同。然后我开始使用 Lambda，我认为几乎是在 .NET 可用于 Lambda 之后就开始使用了。

嗯，那一定是 2015 年或 2016 年，嗯，这实际上很有趣，我从将 .NET 应用程序部署到 Windows 服务器直接跳到了 Lambda，就像我错过了所有中间的容器部分一样，嗯，直接就好像，哦，这些 Windows 服务器太糟糕了，让我们完全忘记服务吧，就像我从来不喜欢基础设施管理一样，我做过一段时间 DBA，就像我从来不喜欢那种东西一样，所以能够直接跳到只部署东西，然后它们就能运行，我记得我第一次使用 Lambda 的时候，就像

我相信大多数人都一样，你只需要部署一些代码，它就能工作，你得到了一个 API，这太棒了。所以是的，从那时起，我主要从事咨询工作。我和很多初创公司合作过，都是大型企业，都使用无服务器，实际上都是 .NET，然后我加入了 AWS。

我在 AWS 的专业服务部门工作，这有时会让一些人感到惊讶，因为我制作了很多内容。我认为人们认为我是一个开发者布道师，但我不是。我在 AWS 是一名顾问。然后，是的，大约三周前，我离开了 AWS，加入了 Datadog。现在我可以一直做开发者关系和无服务器方面的工作了，一直，一直，这非常令人兴奋。你也在和 AJ 合作吗？是的，我也和 AJ 合作，这……

是的，AJ 是一位绝对的传奇人物。所以能够现在和他一起工作作为同事，这很酷。所以，是的。那么我想在这种情况下，是什么吸引你从 .NET 背景转向 Rust 的呢？

冷启动？我的意思是，我认为从历史上看，也许现在不是这样了，但是我认为从历史上看，像 .NET 和 Java 比其他运行时在 Lambda 中遭受的冷启动问题更多。而且这些年来它们都得到了改进。显然，Java 现在有了 SnapStart。

.NET 本身也变得更高效了，例如，使用 .NET 进行亚秒级的代码启动非常容易。然后微软宣布了原生编译，它允许你像编译 Rust 应用程序或 Go 应用程序一样原生编译 .NET 二进制文件。但它仍然不够快。所以最初吸引我的是，我只是想要闪电般的速度。实际上，随着我越来越多地使用 Rust，性能现在已经成为了一种

附带说明。它就像一个好处。语言的许多其他部分都非常令人愉快，非常有趣。但最初的想法是，我只是想要一些速度快的东西。我读了很多关于 Rust 速度有多快的文章，就像每个人一样，我都读了很多。所以是的，我开始学习 Rust。

我想当你提到 .NET 时，你的意思是 C#，而不是 F#。是的。因为我大部分职业生涯都在使用 .NET。但这确实是 C# 和 F# 的混合体。也许到最后，F# 比 C# 更多。当我看到 Rust 时，我认为是在……

我认为在 1.0 之前，它还是 0.3 或 0.4 之类的版本，在 Rust 的早期阶段，我看到了语言工作方式中许多函数式的影响，许多语法和一些异步的东西，我看到了，哦，这看起来真的很酷，因为它与我从

一直在做的 F# 和其他函数式语言非常相似。真正独特的一点是 Rust 的整个所有权系统，用于管理指针和引用，并使它们并发安全。

但是对于 Lambda，一次只有一个请求。所以，好吧，最初当人们谈论 Rust 和 Lambda 时，我在想，关于 Rust 的事情，整个指针系统，安全性，借用等等，你实际上不会得到很多这样的用途，因为 Lambda 是一次运行一个请求。但我认为原生编译的性能方面对冷启动有很大影响。

我实际上认为你关于指针和并发的观点，我完全同意。但我确实认为，怎么说呢？编译器有多挑剔。它实际上比其他语言更迫使你去思考编写好的代码。所以尽管是的，并发的东西在 Lambda 中不一定是问题。

我发现自己可以直接编写更高质量的代码，可以直接编写更少的错误，因为编译器只是，不，James，你不能那样做。你很愚蠢。你需要尝试其他方法。编译器阻止你做很多事情。但是是的，并发的事情在 Lambda 中显然并不那么重要。

是的，我同意这一点。例如，我很喜欢 Erlang。它是一种教你思考异步的语言，因为一切都是异步的。一切都是消息传递。所以你不能逃避这种范式。但这确实迫使你

你知道，从消息解析的角度思考更多系统设计。这实际上很好地转化为我们今天讨论的内容。例如，即使是不同的架构，也都是关于不同的架构组件交换消息。但是如果你一直在使用 Erlang，你就有这种思维模式，你认为一切都是关于消息和顺序的，我想后果就是这样。当你试图将你的架构从代码

转换为 Lambda 函数、事件总线和其他必须相互通信的组件时，它会培养一些更好的习惯。所以是的，我绝对可以理解为什么让编译器迫使你以某种方式做事，从一开始就设计得更好，会在你构建越来越复杂的系统时鼓励更好的习惯，即使你没有充分利用该语言在 Lambda 中为你提供的某些并发方面。

是的，是的，绝对的。我以前不知道 Erlang 的情况。我从未真正研究过 Erlang，但这很有趣，它就像所有消息、所有异步和所有消息传递。这听起来很有趣，尤其是在构建事件驱动系统时。就像你说的，它听起来就像一个无缝的转换。为什么 Lambda 不支持 Erlang？是的。

我想它不是一种流行的语言，而且 Erlang 是一种相当古老的语言。从语法上讲，它与我们今天使用的语言相比并不那么完善。它对开发者不够友好。

但它确实有一些非常好的概念性东西，进程。你可以将 Lambda 的执行环境与 Erlang 中的进程进行比较，它有一个邮箱，一次接收一条消息，它处理该消息，

一个进程内没有并发。所以几乎与 Lambda 的执行环境完全相同。它有一个邮箱，一次接收一条消息，处理它，然后获取下一条消息。所以几乎是相似的模式。你可以在 Lambda 的执行环境中看到这一点。- 有趣。

但是是的，它确实有一些非常好的概念性东西，但它是一种来自 20 世纪 60 年代的相当古老的语言。因此，从语法和围绕它的所有开发者工具来看，它不如你找到的其他东西那么好。这就是为什么大多数人在看到 Erlang 时，实际上使用的是……

Elixir，它运行在 Erlang 引擎上，但它更像是 Ruby 语法，以及来自 Ruby 世界的许多开发者工具，其中比 Erlang 世界更关注开发者体验。是的。

RabbitMQ 是用 Erlang 编写的吗？没错，是的。我们使用的许多系统，如数据库和 RabbitMQ 消息系统，很多都是用 Erlang 编写的。在 Go 和 Rust 出现之前，它是一种非常流行的系统编程语言，因为它在处理大量并发请求方面非常高效。

还有很多其他的东西，比如 gay men jeans（此处应为其他类似的系统，原文可能存在笔误）等等，也是用 Erlang 编写的。因此，对于构建这种高吞吐量系统，Erlang 有一些非常有吸引力的特性。

但这很难。很多电信方面的东西都是用 Erlang 编写的，但很难招聘到人，因为它是一种有点模糊的语言。我认为 Rust 和 Go 的优点之一是它们已经足够主流，现在你可以很容易地为某个职位招聘到人。

但是，你知道，与 JavaScript 和 Python 相比，它在主流渗透率方面仍然排在很后面。那么，这就是你写一本关于 Rust 的书的原因吗？是的，我的意思是，我认为当你开始阅读关于 Rust 的内容时，我认为 Rust 来自于

系统编程，真的。所以 C、C++，Rust 是一种自然的继承者。显然，像这样的语言，其中一个用例是嵌入式系统。你拥有这些资源受限的系统，无论是树莓派还是某个地方运行的小型计算单元。

实际上，我认为当你想到 Lambda 时，你从技术上来说拥有一个资源受限的环境，你拥有内存分配，你拥有少量 CPU，它会随着内存分配而扩展，然后你的成本也会随着内存分配而扩展，对吧？所以实际上，我认为除了我们讨论的所有其他事情之外，性能、语言的优点迫使你做正确的事情……

实际上，Lambda 执行模型，你拥有这些资源受限的环境，我认为它非常适合这些为在资源受限的环境中运行而构建的语言。所以当我们开始写这本书时，我们考虑到了所有这些不同的东西，Rust 可以为无服务器开发者带来的所有这些不同的好处。

围绕速度、性能、资源消耗、可持续性。所有这些不同的东西。我的意思是，Werner 在去年的 re:Invent 上谈到了它。是前一年吗？我不记得了。但 Werner 在 re:Invent 上谈到了 Rust 这种语言。所以 Rust 可以给你带来很多不同的好处，这就是我们写这本书的原因，关于 Rust 在 Lambda 上的应用。另一方面，Jan，但是……

我发现很多 Rust 内容，至少我发现的，有一些例外，都集中在深层内部机制，即语言本身。而且没有很多关于构建真实事物的内容。所以我也是从一个 Rust 开发者的角度来看待这个问题的，就像，好吧，我知道嵌入式系统。我知道系统编程。现在我想构建一个 Web 应用程序。现在我想构建一些像业余项目一样的东西，我将部署它。我将运行一个初创公司，无论是什么。

有一些 Rust 开发者可能不了解无服务器。他们可能习惯于嵌入式系统。所以也有这个角度。我们试图在中间找到一个平衡点，如果你已经是 Rust 开发者，好吧，你可以学习 Lambda，你可以学习 AWS，你可以学习 Dynamo，你可以学习 API Gateway，你可以学习所有这些不同的东西。如果你不是 Rust 开发者，

我们绝不会教人们 Rust，但是里面有足够的内容。而且我们逐步扩展示例，你可以随着学习过程逐渐掌握这些内容，但这绝对不会是 Rust 的入门级教程。嗯，我们开始写这本书有很多原因。嗯，

是的。写书很有趣。这是一项非常艰巨的任务。这是一项非常艰巨的任务。是的。上次我和 Shiana 谈话时，我们也简要地谈到了这本书。他谈到了“简单模式 Rust”的概念。所以，你知道，基本上是用 Rust 为 Web 应用程序编写代码，运行 Lambda，减去所有最复杂的想法，我想，像借用、指针之类的东西，嗯，

正如我们前面讨论的那样，在 Lambda 提供的单请求执行环境中，这可能并不那么重要。但我们看到像 LRT 这样的东西是用 Rust 编写的，这就是为什么它在冷启动方面能够表现如此出色，而且

最近，我们在节目之外谈到了 Datadog 用于跟踪的 Lambda 层，AJ 也将其重写为 Rust。这是一个我为客户项目使用过的 Lambda 层。我看到了……

在冷启动方面的影响大约为 1 秒多，根据 Benjamin Powell 最近发布的内容，它看起来将比这快得多。所以现在你已经和 AJ 合作了，关于为什么它这么快有什么见解吗？仅仅是因为它是用 Rust 编写的吗？

是的，我的意思是，在进入这个话题之前，我还想说的是 Maxime David，他刚刚离开 Datadog 加入 AWS。他也在这个项目上做了很多工作，Datadog 团队内部还有其他人也在从事这项工作。所以 AJ 在这个项目上做了很多工作，但我只想说还有其他人也在从事这项工作。但是是的，所以它已经……所以之前的 Lambda 层的工作方式是将整个……

Datadog 全功能代理的部分作为层的一部分打包，所有这些都是用 Go 编写的。所以这个新的扩展，新的层，抱歉，是从头开始完全重写的。所以它在功能上是兼容的，但它是从头开始完全重写的，基于 Rust，这

为你提供了开箱即用的更快性能，而且二进制文件也更小。我不记得我看到的具体数字，但层的实际大小比

用 Go 编写的那个要小。所以这显然不会像运行时本身那样产生很大的影响，但它会稍微影响启动时间。所以是的，这是一个完整的重写。我还没有真正深入研究代码。我需要去看看。但根据我看到的数字，就像我说的，Ben 前几天发了一篇帖子，我自己运行的测试的数字，

冷启动看起来已经降到了几百毫秒，就像我说的，从 1.2 秒、1.3 秒。所以这是一个非常非常棒的性能提升。一旦它在 GA 中完全可用，它将只是提升你的扩展版本，你的 Lambda 扩展版本。所以不会有……

更改内容、切换环境变量、切换这些，都不会有。它将是相同的层，提升版本，你将开箱即用地获得性能。我试图把它想象成，你知道，当 EventBridge 在幕后做一些神奇的事情时，突然所有延迟都像从悬崖上掉下来一样。我把它想象成与那样相同的方式，那将是升级，突然事情会变得更快，这对每个人来说都是一个胜利。

好的。所以对于不熟悉 Lambda 扩展和这些层的作用的人来说，你能花一两分钟时间谈谈什么是 Lambda 扩展，它是如何工作的，以及这个 Datadog 层是如何为你的应用程序提供额外的可观察性的吗？

是的，Lambda 层是一种运行、打包其他非主要应用程序代码的东西，并将它们与实际的 Lambda 函数代码本身一起设置。你可以打包，我过去见过人们将共享的节点依赖项打包到一个层中。

这通常不是最好的做法。我不知道你是否不同意，但这通常不是我见过的。当我看到人们使用层来打包共享依赖项时，这不会给你带来太多好处，至少根据我的经验是这样。不，我和 AJ 都写了博客文章，说明为什么不应该将共享代码作为 Lambda 层发布。那么我说的没什么太有争议的，很好。但它们真正有用的地方是……

这些几乎就像容器中的 sidecar，这些是你想要与你的应用程序代码一起运行的东西。例如，我在 AWS 工作时参与了一个客户项目，我们需要从 Step Functions 和 Lambda 中管理 Kubernetes 集群。

所以我们将 kubectl 可执行文件打包为 Lambda 层。然后当我们部署我们的 Lambda 函数时，我们只是将这个共享的 kubectl 附加到本地文件系统。然后你就可以在 Lambda 中运行 kubectl 命令了，但你不会在部署的每个 Lambda 函数中都打包 kubectl。你只在层中打包一次。所以这就是我确实看到一些好处的地方

当你拥有这些实际上是共享的东西，而这些东西不一定是应用程序代码时。所以 Datadog 扩展，它做了一堆非常酷的事情。所以它会自动开始提取

来自你的 Lambda 函数的不同信息片段，例如，它将跟踪冷启动，它将监控冷启动，它将监控端到端延迟，如果你将实际的 Datadog 扩展与特定语言的层结合起来，那么就会有 .NET 层、节点层、Java 层，然后你就会开始获得很多自动检测功能，所以今天我早些时候正在处理一个示例，这是在 .NET 中的，但是……

你添加层，你编写一个 Lambda 函数，它接收来自 API Gateway 的请求，将消息发布到 SNS 主题。然后它进入 SQS 队列，另一个 Lambda 函数然后接收并处理它。你开箱即用地获得了整个端到端跟踪，而无需对实际的应用程序代码进行任何更改。

所以它非常非常有用。但就像你说的，在这个扩展的新版本之前，权衡是，你将获得额外的约一秒钟的延迟，就像你说的，这也是我做这件事时通常看到的。对于从 SQS 队列工作的 Lambda 函数来说，这可能不一定是问题。但对于这些对延迟敏感的 API 面向 Web 的 Lambda 工作负载来说，这可能会变得更……

更成问题。所以是的，考虑层的方式是它是你 Lambda 函数旁边的 sidecar。再说一次，请不要将共享依赖项打包到你的层中。而且是的，它允许你，我确定我见过有人，也许是在 Discord 上，他们在 Lambda 中进行 PDF 生成，他们打包了一个可执行文件来生成 PDF。也许不是 PDF 生成。无论如何，是的，那

那是最新的。我想在这种情况下，因为你的 Lambda 层实际上是，你正在交付 Lambda，它作为 Lambda 扩展运行。所以 Lambda 扩展在这种情况下，你可以订阅很多遥测信息。你可以拦截请求，以便你可以

从那里向母舰发送信息，报告我们刚刚看到了这个 Lambda 函数的调用。根据调用事件，我们知道它来自 SQS 中的一些消息。

所以我想下一个问题是，好吧，好的，所以如果之前的代理，好吧，层基本上只是捆绑了这个用 Go 编写的 data.agent，它仍然编译为原生代码，所以我认为性能仍然不会成为问题，因为语言的原因。更多的是它不是专门为 Lambda 编写的，所以它并没有真正考虑太多，好吧，你带来了多少依赖项，它是为不需要过多考虑冷启动的容器化环境设计的，所以更多的是这种设计思想，专门为 Lambda 编写一些东西，你真的会注意你打包了多少依赖项，这就是可能的主要区别，嗯，是的，是的，绝对的，我需要检查核心，但我认为是 AJ，我和他

没有使用 Rust SDK，并且有一个完全成熟的 1.0 版本，功能齐全的 Rust SDK，它具有任何其他语言 SDK 中的所有功能。我似乎记得他们实际上编写了，它实际上是编写的

自定义包装器。所以通常你需要一个 API 密钥才能使用 Datadog，并且扩展支持将 API 密钥作为环境变量传递。不要这样做，大家。不要将你的 API 密钥存储为环境变量。它还支持传入 secrets manager ARN。所以你可以传入一个 ARN 并启动扩展。该层将访问并与 secrets manager 通信，获取你的 API 密钥的最新版本。而不是添加整个

Secrets Manager 的 SDK。只是一个自定义包装器来手动进行该 API 调用，我想这可能是最好的说法，就像你说的，尽可能地最小化依赖项。让我们让这个东西尽可能快，尽可能地最小化依赖项，并使其纯粹是为 Lambda 环境构建的。因为正如你所说，它与在服务器或容器上运行事物非常不同，在那里你可以为它分配更多内存。

我前几天将一个 Java 应用程序部署到 Fargate，我不得不为它分配很多内存。我想，只要给它更多内存，它就会运行得更快。所以 Lambda 在这方面非常不同。事件驱动架构是构建大型系统的强大范例，但它们也因难以在生产环境中进行测试、观察和监控而臭名昭著。

我已在 AWS 上构建了许多事件驱动架构，这些只是我面临的一些反复出现的问题。这就是 HookDeck 的用武之地。它是一个完全无服务器的事件网关。你无需管理任何基础设施。你可以使用他们的命令行界面在几分钟内开始使用。

与 Amazon EventBridge 相比，它可以执行 EventBridge 执行的所有操作。它可以从多个来源摄取事件，过滤它们，将它们路由到不同的目标，并沿途转换事件。但它还提供了更好的开发者体验，包括本地开发体验，以及更详细的指标和日志，以帮助你调试事件传递问题，以及能够轻松查询你拥有的事件，这使得测试变得更加简单。

你今天可以开始试用 HookDeck，并同时支持本播客，方法是访问 hookdeck.com/theburningmonk。好的，你说不要将你的 Datadog API 密钥放在环境变量中，这是我一直以来都在呼吁的事情。那么你为什么认为这不是，好吧，这是一个坏主意？因为有更好的地方可以存放它。这是秘密信息。我的意思是，我不知道。我认为如果你在一个环境中工作，

锁定用户权限，这样他们就不能……我不记得确切的 AWS API 调用是什么，但有一种方法可以锁定，这样用户基本上就不能检索 Lambda 函数的环境变量……所以如果你要做到这种程度的锁定，那么没问题，但这对我来说感觉有点痛苦，需要去调试和弄清楚，并且无法访问控制台，也无法使用 Lambda

鉴于此，至少在我对此进行测试时，使用SSM或Secrets Manager的开销，就我个人而言，在很多情况下，我更喜欢SSM和安全字符串而不是Secrets Manager，主要是因为API调用是免费的。因此，除非您需要执行密钥的自动轮换，否则使用SSM。我发现执行此操作的开销通常不会

太高。因此，我宁愿将其存储在我知道完全适合我正在使用的用途的地方，而不是将可能包含秘密信息的存储在环境变量中。是的，是的。我通常最担心的是环境变量之类的东西。我们从之前的许多实例中知道，这是许多攻击者会瞄准的目标，因为它很容易下手。

很容易进行供应链攻击，只需发布一个恶意的NPM包，它首先要做的事情就是扫描您的环境变量，并将任何内容报告给它们自己的后端，以便它们可以收集人们环境变量中的任何内容。

人们可能会在环境变量中加载连接字符串、数据库IP地址、用户名、密码以及访问数据库所需的一切，以及您可能使用的各种SaaS服务的API密钥。

这就是我通常在将敏感信息放入变量时所担心的问题，因为即使有人无法渗透实际的Lambda，Lambda，运行您的Lambda函数的每个两个实例，因为这是由AWS保护的。但所需要的只是下载

NPM包或已被破坏的东西。我们已经看到了许多这样的例子。或者有人……我们还看到了有人发布名称略有不同的包的例子。因此，而不是cross-hash、cross-dash nth，它将是cross-underscore nth。因此，您认为您正在下载官方包，但您正在下载某人的伪造版本，它执行相同操作。但是

当您启动时，当您需要它时，以及在运行时，它将扫描您的环境变量。这就是我担心的问题，与其说是从控制台访问数据，不如说是，好吧，如果有人……

可以很容易地提取这种文本。这就是为什么我倾向于使用，就像您所说的那样，使用SSM或Secrets Manager。我通常采用的方法是在成本上获取它们并将其缓存。然后，对于我想轮换的内容，偶尔使缓存失效，或者如果我知道某些内容永远不会改变，则将其永久缓存。

这也是一个选择。我的意思是，我认为我过去使用过一些SaaS产品，而且我不太了解Datadog。所以这不是……我不一定知道Datadog是否如此，但我发现过去生成的许多API密钥都是只写类型的，我认为如果攻击者是写操作或……我认为这在某种程度上降低了风险。他们可以进行拒绝服务攻击，并将大量日志发送到您的系统中。但是……

是的，我从未想过那样，实际上，扫描环境变量。这是一个很好的观点。很有趣。我相信我过去在使用Kubernetes时，我相信Kubernetes中的所有密钥都作为环境变量安装。我相信这就是它们的工作方式。

它是12要素应用程序的组成部分……这就是我刚才在谷歌搜索的内容。我相信这是12要素应用程序，可以在几分钟内完成任务。是的，这使得您的应用程序可以轻松访问它，但也使得任何能够在您启动时在您的执行环境中运行代码的人都可以轻松访问它。所以……

我不知道。这是一件非常好的主意。也许是人们在整个新的云构建和云计算仍然很新的时候想到的最好的主意。但仅仅因为它曾经是一个合理的想法并不意味着我们必须

坚持它，所以我认为我们确实必须随着新的攻击载体的出现而随着时间的推移而发展，但这是我个人的看法，有些人强烈反对我的观点，因为实际上很难渗透安全环境，但是

但我更担心的是，好吧，需要一个错误的依赖项，一个恶意的依赖项，他们不必实际渗透您的执行环境，而只需渗透您的代码。是的，是的。我的意思是，回到Rust，我想我找到了一篇论文。我在今年早些时候做了一个关于Rust和Lambda的会议演讲，我发现了一篇由

多个政府机构发布的论文。所以就像CIA、英国的GCHQ、加拿大、加拿大网络安全团队、澳大利亚、法国，有很多国家。他们发布了这份关于每个人都应该为了安全目的而采用内存安全语言的联合论文。

显然，Rust的所有权模型的工作方式以及没有垃圾收集器的事实，内存只保留……事物只在需要的时间内保留在内存中，然后它们就会被丢弃。编译器检查所有内容的方式确实使其成为一种令人难以置信的……

内存安全语言，如果不是最安全的内存安全语言，我可能会争论，而且显然这不会解决环境变量问题，人们当然仍然可以在Rust中扫描环境变量，但是存在一系列在Rust中根本不存在的内存安全类型问题

我的意思是，如果联邦调查局和GCHQ以及所有其他网络安全人员都说我应该这样做，那么我认为我可能会在某个时候听取他们的意见。所以它也有这个角度，比如Rust的安全角度。好的。好的。我还记得那篇论文，我理解为什么这是一个好主意，因为过去有很多数组溢出、缓冲区溢出之类的攻击。但对于不熟悉内存安全含义的人来说，你能为我们定义一下吗？

因此，无论何时您在计算机编程中执行任何操作，您保留为变量的任何数据，无论是您存储的任何内容，都将存储在一段内存中。天哪，我已经很久没有解释过这个了，Jan。我已经很久没有解释内存安全了。

如果您，让我们假设一些JavaScript代码。我可以将JavaScript中的变量设置为字符串。

然后我可以将该值设置为null。我可以将该值设置为其他内容。然后我可以在我的应用程序代码中稍后尝试再次重用该变量。那时，该变量将不再具有值。该变量将为null或undefined或任何其他内容。如果我尝试访问其中的某些内容，那么我的代码将爆炸，因为该内存块实际上不再存在了。

现在在Rust中，由于所有权的工作方式，这几乎是不可能的。因此，如果我声明一个变量，然后该变量超出范围，Rust将立即将其从内存中删除，并且编译器将告诉我。因此，如果我尝试再次重用该变量，

编译器将不允许代码编译。它会说，你有一个变量。它已被从内存中删除。您正在尝试重用它。它将不再存在。你实际上不能这样做。所以，我的意思是，这只是一个关于内存安全的非常简单的例子，我想。但这就是您所遇到的那种情况，您在内存中有一些东西，它们可能存在也可能不存在了。它们可能会溢出。

是的，是的。我不知道你是否有一个更好的定义，Jan，因为我已经很久没有做过这样的事情了，这实际上是一件有趣的事情，我过去在编程中遇到的一些困难之一是因为我没有接受过经典的计算机科学培训。这些概念中的一些东西，Rust中的一些东西，我就像，那是什么意思？我需要很长时间才能理解这些东西，因为我没有接受过经典的培训。

是的，我认为如果您使用的是.NET、甚至JavaScript，您不必管理内存，那么很难概念化这意味着什么。我过去做过一些C++，您必须分配一块内存，您必须维护指针。这就是缓冲区溢出很容易发生的地方，您分配一堆内存。

但是然后你给某人一个数组，然后不知何故进入一个你试图访问超出数组边界在内存中的位置的位置。但是如果编程语言运行时没有保护，这意味着，好吧，有人尝试访问索引10，而只有9个项目。

这意味着他们无法读取内存中第10个位置的内容。他们能够读取不属于数组的内容。这就是您拥有——并且像我说的那样，当事物超出范围时，它们不会被清理，它们仍然在内存中，这意味着能够诱骗程序溢出指针以便它们超出该数组边界的人，

然后他们可以开始从不属于您试图让它们读取的内容的内存中读取信息。这就是我们过去在文本方面看到的许多事情的来源

操作系统或程序能够读取计算机中永远不应该读取的信息，这是因为能够扫描大量此类信息并将其重新组合在一起，因为他们能够诱骗程序继续增加缓冲区、指针并读取越来越多的内存片段，然后，好吧，他们基本上只是获得了应用程序的内存转储，然后他们将其重新组合在一起，看看，好吧，我们有什么信息？

因此，如果您必须自己处理内存分配和管理，那就是内存安全性的相反端，内存不安全，很容易让自己处于返回永远不应该返回的数据的位置，因为A，它们在那里，而且B，您没有阻止人们能够读取程序中预定边界之外的内容。这就是Rust之类的东西

我认为许多其他程序、其他编程，不仅仅是编程语言，现在都具有这种保护措施。是的，是的。我们应该指出同一篇论文。我认为它还提到了rust.net、Java……

也许是go，我不确定。这篇论文中不仅仅是Rust。如果您不是Rust开发人员，并且现在感到害怕，因为联邦调查局说您不能这样做，那么您可以这样做。我们可以将链接放在节目说明中，对吧？到实际的论文本身。哦，是的，这是一个很好的观点。是的，我也会将该链接放在节目说明中。是的，那里不仅仅是Rust，每个人。是的，我认为大多数，我想，现代编程语言现在都具有这种功能，因为它一直是……

多年来的安全问题，嗯，你知道，但我们现在不知道我们是第几代语言了，但是是的，我认为大多数语言不仅仅是语言，都会知道会解决这个问题，我觉得我应该去尝试编写一些C和C++，我认为有一些东西，我认为这是一件你想放在LinkedIn上的事情，你就像你应该总是尝试理解比你实际理解的更深一层，也许我应该去编写一些C和C++，实际上只是因为我认为这是一件非常有趣的事情，

我发现自己经常思考的一件事是，对于那些在软件行业工作了相当长一段时间、习惯于将东西部署到服务器的人来说，无服务器就像太棒了。这就像有史以来最好的事情。但是，一定有一大类现在才开始的开发人员只知道无服务器。就像，好吧，我想知道如果你从未处理过凌晨3点自动关闭的Windows服务器，你是否会同样欣赏它。这很有趣，不是吗？我想知道我是否也应该对编程做同样的事情，然后学习C语言。是的。

是的。我说的是，你应该总是理解你想要工作的层之下的一到两层，因为这些层效率不高。你每天都想提高效率。但是，了解幕后事物的工作原理确实可以帮助

让你了解为什么服务器如此出色，为什么我们这么多人都如此热衷于服务器，因为我们很多人都在经历管理服务器的经历。就像我说的那样，机器在凌晨3点爆炸，或者内存需要两周时间才能被注意到。然后你花几个月的时间试图弄清楚，好吧，这是从哪里来的？重新启动服务器，然后它再次启动，然后两周后它再次崩溃。是的。

我过去曾经遇到过.NET应用程序的这些内存泄漏问题，我们有大型对象堆。我们创建了大量我们没有意识到的大型对象。它基本上导致了内存碎片。内存在那里，但它们只是没有被

它们不可用，它们不可分配，因为大型内存堆不会在正常的L1和L2 GAN对象集合上被清理。因此它们会累积并占用大量空间，当它们被销毁时，它们会留下大量空隙。因此，您拥有的内存量仍然相同，但实际的可寻址内存空间越来越小。

随着时间的推移，这意味着您的应用程序内存不足，即使内存仍然存在。因此，我们过去曾经为此特定应用程序使用过这个克隆作业，它基本上每两周就会回收一次机器。因为我们知道内存分配大约需要两周时间——好吧，内存问题才会出现。

我们从未真正弄清楚真正的问题是什么。我们知道症状。我们有一些理论，但我们尝试了一些方法。没有什么效果。因此，最后，好吧，让我们做一个cron作业来偶尔踢轮胎。所以，你知道，有很多像这样的问题，你再也不用担心Lambda了。并且了解，你知道，如何管理机器，运行它，

我认为这是一个非常有用的技能，可以理解，好吧，没有什么魔法。有些是lambda魔法，但这只是工程。人们正在选择好的工作。同样，我们用rust做的事情，所有这些，都不是魔法。这都是关于工程和理解幕后事物的工作原理，这可以帮助您理解某人可能做出的决定，以达到在rust中我们不再有这种内存函数的程度。

安全问题了。我认为这也有助于您欣赏我们今天拥有的好东西。是的，绝对的。我们确实过得很不错。因此，对于像只使用HTTP API之类的事情，您也应该仍然了解IP和UDP的工作原理。您可能不会使用它，但至少您了解协议，以便您了解为什么

HTTPS更昂贵，当人们谈论，好吧，有更多的往返行程和握手等等时。以及为什么网络连接较差的国家的移动设备

你知道，有更多的往返行程。因为你知道，消息、确认被丢弃，以及TCP如何从中恢复等等，事情正在发生。您可能不需要它，但了解这些事物的工作原理会很好。因此，您将拥有更完整的思维图景。是的，我的意思是，我甚至会对Lambda说同样的话，就像了解Lambda在内部如何工作一样。就像我过去喜欢看Julian Wood的一些演讲一样，他深入探讨了Lambda的内部结构以及它的实际工作方式，因为它只是，

它可以帮助您理解为什么事情是这样的。我认为，我不知道，冷启动非常有趣。我觉得他们已经被谈论死了。但是当您真正考虑正在发生的事情时，假设您有一个具有千兆字节内存的Lambda函数。请求正在进入，Lambda服务将在某个地方寻找一台具有备用千兆字节内存的机器。它将分配该位环境，保留该千兆字节，

启动执行环境，下载您的代码，启动运行时，然后将有效负载传递到该环境中。您的代码将运行，然后返回。所有这些都将在700毫秒内发生。这是什么？当我想到它时，我的头会疼。因此，我认为深入了解这些内部内容确实会让您欣赏，好吧，幕后实际上发生了很多事情才能运行此程序。

是的，所以我认为他做的最后一个是在2022年吗？他做了，我不认为去年有一个。通常情况下，就像连续几年一样，他们进行了这个Lambda深度挖掘会议。我认为Julian做了最后一个。我真的很喜欢这个演讲。

他们谈到的一件事是，他们为改进整个性能所做的一件事是，使调用链中的大多数服务成为有状态服务。这样做的原因是它消除了对数据库调用的调用，因为机器本身、服务器具有状态，这当然会使系统更加复杂。但是

这意味着在美好的一天，在一个良好的请求中，他们立即知道哪台机器有空间，因此他们不必调用其他调查或数据库来找出，好吧，给我我们拥有的服务器、机器的列表，它们可用的内存空间量，然后尝试将其分配给其中一台机器。他们在机器上、在服务器本身上知道，好吧，每当分配一台机器来处理或分配另一个Lambda函数实例时，

它们会立即反映在机器的内部知识中。所以，是的，我喜欢这个演讲。我也会将链接添加到节目说明中。我认为最新的一个来自2022年。

您还有其他演讲吗？您提到您做了一个关于Rust的演讲。您有该演讲的链接吗？我也可以将其放在节目说明中。我不知道它是否被录制了。我会尝试找出答案。我在YouTube上有很多东西。我在YouTube上有很多关于Rust和Lambda的内容。我也会将您YouTube频道的链接放在这里。太棒了。谢谢。所以是的，我认为那实际上并没有被录制。我希望今年能再做几个关于Rust的。每当我做Rust演讲时，我都会觉得很有趣，因为我对Rust很陌生。我一直在学习Rust 12个月，也许是18个月。

当我做这个演讲时，前排有一位经验丰富的Rust程序员。

我几乎可以看到他们，你在说什么？就像，你不是，你不是，你没有，像，没有正确表达。是的，我认为我对公开演讲的态度是我不喜欢完美是好的敌人。我喜欢站起来分享事情。如果我没有正确表达，那么希望有人会指出我的错误，我下次可以更好地表达。但是是的，这有点可怕，尤其是一些Rust程序员就像这些铁杆的，比如，系统，比如，嵌入式系统程序员。所以去Rust会议上演讲比其他任何会议都更可怕

会议，我认为我向所有人说晚安很有趣，是的，大致可怕，是的，当我，你知道，所以与函数式编程社区一起闲逛时，很多人，你知道，是真正的铁杆语言研究人员、语言创造者，所以，你知道，那些会议是一种非常不同的体验，嗯，有很多会议我真的很喜欢，比如美国的strange loop，那是代码光束，嗯

由Erlang Factory在英国举办的会议。这有点像他们试图成为一个奇怪的循环，在那里，许多更前沿的语言研究内容在更主流的环境中被讨论。而且你有很多从事语言研究的人，我不知道，几十年了。你有一些人，比如Erlang的创造者、Fsharp的创造者，以及像这样的人在谈论语言研究中最新和最伟大的事情

我过去尝试过的变化最大的语言之一。我经历了一个尝试许多不同编程语言的阶段。

是这个叫做Idris的东西，它是一个依赖类型系统，他们实际上可以将类型信息发送到网络上。然后在另一端，他们也可以验证，好吧，您发送的信息是正确的。他们还可以对数组的长度进行类型检查，而不仅仅是

数组中的对象类型，还有数组的长度，这可以成为您类型上的约束的一部分，这当然对于更复杂的系统来说可能很有趣，但这更多的是从研究的角度来看，好吧，我们可以将类型系统推到多远？当您将其与C#之类的东西进行比较时，好吧，您知道，那是类型系统，然后那是类型系统。是的。

是的，绝对的。我最近几天写了很多Node，而且我

没有类型系统真的很困难。太难了。我的.NET大脑真的很难处理它，因为我想，等等，这可能是字符串，但也可能是数字。你是什么意思？你是什么意思，JavaScript？我认为对于Lambda，我没有发现它是一个太大的问题，因为我的大部分代码只是一到两个文件。因此，抽象层并没有很多。但是当我使用一些更传统的代码时，

Node Express应用程序。就是这样，取决于我正在查看哪个文件，用户的意思完全不同。没有类型定义，所以我不知道我可以对这个用户对象有什么假设，你必须返回多个文件才能看到，好吧，它在哪里被解析以及追溯到开头。好的，那是用户类型，然后你弄清楚，好吧，你可以用这个对象做什么？

但是是的，我认为传统的Web开发，当应用程序变得复杂时，您需要类型才能提高效率。但我认为Lambda，我能够应付没有类型的情况，并且我对节点应该比TypeScript更满意。是的，绝对的。所以我想最后一个问题是，你现在在Datadog工作，你会做什么？

所有无服务器的事情。实际上，我最近一直在思考的一件事与，你知道，互联网上流传的关于无服务器已死以及无服务器现在实际上意味着什么的文章有关。我认为，我的意思是，我们线下稍微谈论了一下，只是稍微成熟了一点。我认为我现在真正感兴趣的是……

相互作用，我想，容器和函数之间。我认为将事物称为无服务器变得棘手。我认为您有部署到容器的应用程序，也有部署到事件驱动函数的应用程序。那么，充分利用两者的现代系统是什么样的呢？我最近一直在研究的一种模式是，您有一个部署到非常小的Fargate容器的非常薄的Web层。这给了你一个非常……

对前端的性能响应时间，但是您所有的后端功能，您所有的异步内容都转移到lambda中，那么两者之间的相互作用是什么样的呢？您如何理解它，显然，数据可观察性是一件大事，如果您在fargate上有一些应用程序，在lambda上有一些应用程序，也许您有一些都在lambda上的微服务，那么这种相互作用是如何工作的呢？所有这些东西是如何协同工作的呢？这就是我现在特别感兴趣的，比如这个

下一阶段的软件开发听起来真的很宏伟。它不会那么宏伟，但是，它实际上是什么样的呢？因为，你知道，我现在已经使用Kubernetes很多了。我仍然不明白。说实话，我就是不明白。我的意思是，我认为，我认为我听过的关于Kubernetes最好的启发式方法之一是，如果您正在构建一个系统，其中动态扩展基础设施的能力是您业务的核心差异化因素，

那么Kubernetes很棒。就像我想想如果您正在构建一台机器，您知道，您是像ChatGPT或Anthropic这样的人，您需要动态地即时扩展和缩减基于GPU的实例并管理所有这些，它们很棒。但是对于大多数公司来说，

我认为它的运营开销过高。但他们可能仍然想使用容器。您可能仍然希望容器成为您的操作模式。好的，您如何以更无服务器的方式使用容器，而不是仅仅认为无服务器等于Lambda？所以是的，我回答这个问题的方式很冗长。对不起，安妮。但是是的，我感兴趣的是这种现代应用程序之间的相互作用，我们应该说它们仍然是无服务器的。是的。

是的，我认为，是的，整个无服务器债务问题已经持续了一段时间了。所有这些都是由AWS解散其无服务器宣传团队引发的，即使这只是一个组织变革。他们正在调整事情。他们更关注人工智能。所以，你知道，他们去年也解散了Kubernetes团队。我并没有听到有人说Kubernetes已经死了。是的。但是是的，

但我认为这部分可能反映出他们可能不需要做那么多宣传工作。周围已经有一个庞大的社区。我认为Marcia写了一篇博客文章，解释了他们这样做的部分原因是

整合宣传团队，而不是为不同的范例组建更专业的团队。但我也认为我们可能应该，我认为Ben，Ben Cahill之前在这个播客中谈到过这个问题，即无服务器这个术语应该消失，并且有希望最终消失，当人们开始像使用其他事物一样使用它们时，而不是需要某种营销术语来吸引人们

完全同意。是的，我认为，这有点好笑，我认为我的职位是无服务器开发者宣传员，而我刚刚同意我希望它消失。但是，是的，我的意思是，我同意。我认为人们应该谈论函数、事件驱动的函数、反应式函数或容器。它们是机制。将所有东西都归类为无服务器。是的，我不确定这一点。

我认为它在开始介绍一个新概念方面很有用，因为它是一种不同的思维方式。但最终，就像NoSQL一样，现在没有多少人谈论NoSQL了。我认为有人告诉我，AWS内部仍然有NoSQL专家团队。但对于我们这些客户来说，我们只是谈论DynamoDB。我们不再将其视为NoSQL数据库。我们只是将其视为DynamoDB。我们谈论其他数据库，就像

你知道的，这个数据库和那个数据库。我们知道它不是SQL。你知道，你不会编写SQL查询来与这些数据库对话。但是……

NoSQL这个术语不再是一种有用的标记事物的方式了。现在人们，你知道，每个人都开始理解SQL与不运行SQL引擎的数据库之间的区别。但是，是的，我想现在人们谈论的是键值对、时间序列、关系型或其他什么。所以，我喜欢这种看待它的方式。

是的。所以我认为无服务器对于介绍这种思维方式很有用，这种思维方式更偏向于托管服务。这更像是即用型服务，你无需担心或自己运行基础设施。但我认为，随着越来越多的服务真正成为无服务器服务，例如DynamoDB、S3，我们对无服务器的真正期望是让人们转向一种更偏向于服务的思维方式，而不是运行机器然后再运行你的软件，而是使用服务，你知道的，

并使用不同的服务组合应用程序，以便你将更多责任委托给这些提供商，而不是自己运行所有内容。这就是最终目标，希望我们能够实现这个目标，然后我们可以抛弃无服务器这个标签。不过，这真的很有趣。当我在贝尔法斯特无服务器大会上时，我与Dave Anderson交谈，

价值飞轮效应的作者。如果你不认识Dave，就去看看他的作品。他很棒。他一直在和一个认识的人交谈，这个人为一家使用Kubernetes的公司工作。但实际的开发者却说，我正在使用无服务器，因为开发者自己没有

他们只是推送了一个容器，然后容器就在某个地方运行了，我认为这很好。但我认为你几乎又回到了dev和ops的世界，在那里你有一个团队运行Kubernetes集群，你还有开发者，而开发者只是将容器扔过墙。就像我担心我们会回到那种状态。而构建所谓的无服务器系统，几乎所有事情都是你作为开发者的责任，我认为这实际上是一个缺点，那就是现在所有事情都是我作为开发者构建的责任

弄清楚我的Lambda函数是否并发执行过多等等，这都成了我的责任。但我认为让开发者承担更多责任是一件好事。是的。责任一方面是一枚硬币的一面。另一方面是权力。你可以做更多的事情，自己做更多决定。但我认为，要弥合拥有这种能力与承担责任之间的差距，关键在于，你知道的，

能够，你知道的，能够承担这种责任。我认为这就是教育仍然非常重要的原因，因为，你知道的，当我们谈论无服务器时，我认为Gregor Hopp创造了一个很棒的术语，即无服务器是真正的云原生，因为这是云希望你构建软件的方式。

但要正确地做到这一点，你必须真正了解云。这就是理解你正在使用的服务、IAM、它的工作原理、如何正确创建正确的权限以及类似内容的原因。因此，当我们越来越左移时，安全、架构决策、

DevOps、自动化、部署，我认为所有这些事情在使用无服务器、Lambda等等时都更容易做到，因为大部分都是托管的。你只需要选择正确的设置，然后就可以开始了。在维护方面没有持续的工作，例如，你必须修补机器等等。不需要那样做，而且

许多组织，至少大型组织，都有平台团队可以处理多个团队的某些横切关注点。例如，正确设置帐户，设置AWS配置以及所有其他设置以强制执行一致性、最佳实践以及为CDK创建L3结构等等。

但是，是的，你是对的。开发人员的责任更多了，但我认为这些责任也更容易履行，但这需要正确的教育和正确的人才。虽然你这么说，但很有趣。我昨天用Lambda、SQS和Lambda做了一些事情，我做了全部工作，没有正确设置DLQ。

我收到了一条通知。这一切都是，我一直在玩Datadog，所以我把它全部连接到Datadog中。我收到Datadog发来的电子邮件，说你的Lambda函数在过去一小时内执行了1200次。因此，很明显，消息只是在队列中一遍又一遍地循环。所以，是的，尽管你这么说，它需要教学和经验。所以，我在这里，一个正在创建内容和教学的人，仍然设法把它搞砸了。所以……

是的，这几乎就像每个人都会被烧伤一次一样。循环递归。是的。是的。但是，这不会让lambda……所以，我认为lambda现在有这种支持，不是吗？也支持SQS。他们认识到这一点，因为它会为SQS和lambda循环。

我要说不行。我不知道，但我要说不行，因为它昨天发生在我身上了。但也许，也许是某些东西。也许只是SNS。我知道有很多事件作为触发器。它能够主动识别这些事件并在看到递归调用循环时停止它们。是的，我用S3见过这种情况。我以前被S3烧伤过，将文件放入S3存储桶中，触发函数，然后返回到S3存储桶，然后我们继续。是的。

所以是的，我支持AWS。哦，是的，SQS。它说它确实支持SQS。那很有趣，因为它昨天没有用。无论如何。

好的。所以，是的，James，非常感谢你今天抽出时间与我们交谈。我想在我们结束之前，这本书进展如何，人们可以在哪里阅读这本书？你可以在rust-lambda.com上购买这本书。这是本书的登录页面。我们正在边写边发布。所以我们已经完成了前四章的草稿。它们是完整的章节。

尚未审查，但如果你今天购买这本书，你将立即获得前四章，并且

这本书的前提是你将构建一个链接缩短应用程序。就像bit.ly这样的东西，你实际上将在Rust和Lambda中构建它。所以在第四章结束时，你将拥有一个完全运行的链接缩短器。你可以提交一个链接，你会得到一个短代码，然后你可以点击该短代码，它会自动将你重定向到实际的底层URL。嗯，是的，如果你访问rust-lambda.com，这本书，我认为现在有40%的折扣。

随着我们编写和发布越来越多的内容，随着我们发布更多书籍，这将逐步增加。所以，是的，rust-lambda.com。我认为我们可以在节目说明中添加链接。所以，是的，它正在进行中。我实际上周五与Luciano有一个会议，试图弄清楚我们接下来要做什么。我们已经完成了所有章节的草稿。我们已经完成了大纲草稿，所以你可以访问网站。你可以确切地看到我们将要介绍的内容。我们只是在编写章节时添加它们。

好的，好的。祝你好运。期待重点完成时。我已经有了早期资源，所以我也会关注新章节的更新。任何反馈，如果你确实购买了这本书，即使是你，Jan，如果你阅读了任何内容或看到了任何内容，那么我们俩……

除了作者对你永恒的感激之外，我们什么都无法提供给你。你只能得到这些。哦，我们也有很酷的贴纸。所以，如果你在任何地方看到我和Luciano，那就问问我们。我们有一些像戴着帽子的Lambda，戴着帽子的Rust，对不起。Ferris，语言的吉祥物，戴着Lambda帽子。所以，是的。好的。祝你好运。希望9月份能亲自见到你。是的，同样。太棒了。干杯。保重。好的。再见。再见。

感谢HookDeck对本集的支持。你可以了解更多关于HookDeck如何改善构建事件驱动架构的开发者体验的信息。访问hookdeck.com/theburningmonk。

这就是另一集《真实世界的无服务器》的全部内容。要访问节目说明，请访问realworldserverless.com。如果你想学习如何构建可用于生产环境的无服务器应用程序，请查看我在productionreadyserverless.com上即将推出的课程。我们下次再见。