#105: The inception story of Cognito & secret to succeeding at AWS | ft. David Behroozi
01:14:51 Share

本期节目由 Memento 赞助，Memento 是一款您可以信赖的无服务器缓存，并且只收取您使用的费用。要了解更多信息，请访问 goldmemento.co/theburningmonk

大家好，欢迎回到《真实世界无服务器》节目的结尾，这是一个我与现实世界中的实践者交谈并讲述他们背后故事的播客。今天，我邀请了一位非常有趣的嘉宾参加节目。我邀请了 David Beruzzi，他曾在 AWS 的 Cognito 团队工作，现在他已经独立工作了一段时间了。所以，David，欢迎来到节目。你好，Jan。很高兴来到这里。

是的，我们在社交媒体上聊过很多次，分享了很多关于各种不同事情的想法。所以我很高兴能让你来这里谈谈你一直在尝试的一些事情。但也许你首先想做一个简单的自我介绍，说说你一直在做什么，你的背景等等。

当然。我想最有趣的事情是，我在亚马逊工作了 15 年多，并且一直值班。我是一名亚马逊的开发者，在第一线编写代码。我从亚马逊零售部门开始。然后在大约 2013 年，我转到了 AWS。

在那里，我编写了 Amazon Cognito 的一些第一行代码。我们构建了整个服务 Cognito Identity、Cognito Sync 和后来的 Cognito User Pools。然后在大约 2020 年左右，我转到了 Amplify Hosting。这是一个完整的 CI/CD 产品，用于在像 CloudFront 这样的 CDN 上托管现代 Web 应用。

我在 2021 年离开了亚马逊，开始探索我在无服务器领域的一些更大胆的想法。我有一家公司，在那里我正在开发一个名为 Speedrun 的产品。它每天都在变化，但我今天对它的描述是，它是一种巧妙地使用 Markdown 来构建工具以加快您的手动任务的方法。我希望我们今天可以谈谈这个。

我最近成为 AWS 无服务器领域的社区建设者。我一直在探索 Lambda、边缘函数和可观察性，并撰写博客文章来扩大我的影响力。我很高兴今天能和你谈谈 Cognito 及其历史和起源故事，以及你对我提出的任何问题。

是的，听起来不错。而且我没想到你还参与了 Amplify Hosting 的工作，这也是我所有副项目中经常使用的一项服务，所有登陆页面都托管在 Amplify Hosting 上，我认为，遗憾的是，很多人甚至没有意识到它的存在。他们想到 Amplify，就会直接跳到 Amplify CLI。所以每次我提到它的时候，

Amplify Hosting，人们都没有意识到这是一项服务。最近，CloudFront Hosting Kit 推出了。我问了一个问题，好吧，现在这是一套全新的工具包，允许人们自定义 CloudFront 分发，而你无法使用 Amplify Hosting 来自定义。改进 Amplify 以提供更多关于 CloudFront 分发本身的控制岂不是更好吗？

人们立刻就开始跳出来说，“是的，但是 Amplify，你什么都无法自定义，只有 CLI。”但随后我说，“好吧，我这里说的不是 Amplify 的那一部分。”是的，在我们讨论这个之前，也许让我们先谈谈 Cognito 背后的起源故事，因为你从一开始就在那里。是的，告诉我们幕后这个服务是如何产生的，以及你看到的一些事情？

是的，我刚加入 AWS 移动团队，移动团队的任务是构建 AWS Web 服务的抽象，以满足移动应用开发人员的需求。例如，我们有一个名为 S3 Transfer Manager 的东西，当你在像移动设备这样的连接不稳定的环境中时，

你的连接会不断中断。因此，能够上传和恢复你对 S3 的上传非常重要。因此，我们构建了一些 SDK 来帮助实现这一点，包括

Android 和 iOS SDK。我们正在研究诸如进行地理查询之类的事情。我认为在那个时候，报告你当前的位置并查看你的朋友在哪里非常热门。因此，我们构建了一个库，允许你使用 DynamoDB 上的地理查询来查看附近的人等等。我们只是试图让移动应用开发人员更容易地在 AWS 之上构建应用。

而且不断发生的一件事是，人们会将他们的 AWS 凭证嵌入到他们的应用程序中。不可避免地，在某些时候，有人会发现这一点，反编译他们的应用程序，并开始在他们的 AWS 帐户中造成破坏。因此，最佳实践是构建一个名为令牌售货机的东西，你的应用程序会向这个

端点发出请求，它会说，这是我，进行某种握手，它会从云端获取临时范围缩小的凭证，这有点像简单的令牌服务所做的。但这正是我们提倡的做法，而不是将你的凭证嵌入到应用程序中，而是这样做。

所以我认为在 2013 年的 re:Invent 上，我们试图推出的是一个 SDK，它使你能够将少量用户数据同步到 DynamoDB 数据库。当时，人们刚刚开始

使用多台移动设备。因此，他们可能有一部 iPhone、一部 iPad 和一台电脑，他们希望将所有数据同步到这些不同的平台之间，以便他们可以继续之前的工作。所以在加入团队之前，团队已经构建了这个 SDK，它允许你

有一个令牌售货机，你可以从中获取凭证，然后从你的应用程序中，你基本上是将你的保存的游戏或你的偏好同步到 DynamoDB。然后还有一个库可以帮助你将其同步到所有移动设备上。因此，如果你在手机上看到了它，那么你就可以立即在 iPad 上看到更改，诸如此类。

我认为我们将此提交给领导层，他们说：“太难了。这不会发布。这太粗糙了，而且不是我们想要交付的东西。是时候开始专门为移动设备构建 AWS 服务了。”因此，有了这个任务，我们

拿回了设计，我们花了几周时间来构建一个 Web 服务来完成这项工作，这就是 Cognito Identity，它为你提供身份和临时时间范围的凭证，可以直接访问

AWS Web 服务和 Cogito Sync，一旦你有了身份并希望跨你的 Web 和移动设备同步少量数据与该身份相关联，你就可以使用同步功能。所以我们花了几周时间进行设计，我记得，我认为是在四月，我们得到了一个发布日期。我们被告知我们需要在芝加哥峰会上发布。

那时我们只做了一点原型设计，我告诉我的经理，现在是时候了，我们需要交付这个东西，我们的时间不多了，所以这是一个大约三个月的冲刺，我们从头开始构建这些 Web 服务，经历了构建 AWS Web 服务的整个流程，并在 2014 年 7 月 10 日的芝加哥峰会上发布了它们。其余的就是历史了。

这个发布计划是针对 AWS 服务的，所以我认为有时这肯定很有挑战性。我知道每次 re:Invent 来临的时候，与许多服务团队合作，情况就是这样，“好吧，我们有很多想要发布的想法，但是总是有这个迫在眉睫的截止日期，这个 re:Invent，很多事情都会被压缩，并在 re:Invent 期间发布。”我想现在也有一些东西在一些峰会上发布了。

我想问你的一件事是……好吧，也许我们稍后再谈。既然你正在设计 Cognito，那么最常见的用例是什么？

我的意思是，就我个人而言，我主要看到人们将 Cognito 与 API Gateway 或 AppSync 一起使用，而这种集成可能是我一直使用 Cognito 的最大原因。那么，从你的角度来看，在团队中工作，人们对 Cognito 的一些最常见的用例是什么？是的，有一些用例。让我再谈谈 Cognito 用户池。所以……

Cognito 用户池于 2016 年推出，这是因为 Cognito Identity，你可以是匿名访客，也可以从其他地方联合登录。我们确实有一个名为开发者认证身份的功能，你可以在你自己的用户名和密码数据库中进行身份验证。但是人们真正想要的是让我们

提供一个用于用户名和密码以及 MFA 等内容的交钥匙解决方案，这就是 Cognito 的用户池组件，但回到你的问题，什么是常见的用例，所以有一些用例，让我再谈谈 Cognito 用户池。所以……

Cognito 用户池于 2016 年推出，这是因为 Cognito Identity，你可以是匿名访客，也可以从其他地方联合登录。我们确实有一个名为开发者认证身份的功能，你可以在你自己的用户名和密码数据库中进行身份验证。但是人们真正想要的是让我们

提供一个用于用户名和密码以及 MFA 等内容的交钥匙解决方案，这就是 Cognito 的用户池组件，但回到你的问题，什么是常见的用例，所以有一些用例，例如，允许你的移动应用程序直接访问 AWS，这就是 Cognito Identity，如果你需要将

点击流信息发送到 Kinesis，或者你需要允许你的最终用户访问 S3 存储桶的一部分，例如，他们图片的私有存储，或者 DynamoDB 表的一部分，例如，以他们的身份 ID 开头的键，以便他们可以存储键值对。因此你根本不需要后端。因此，从你的移动应用程序直接访问 AWS 的全部功能。这是一个用例。

另一个用例是，你需要保护你的后端。你有一个使用 API Gateway 和 Lambda 或 AppSync 等编写的后端，你需要对你的用户进行身份验证并保护对后端的访问。你不想把它公开。你需要对你的用户进行身份验证并使用令牌授予访问权限。

有一些与 IoT 相关的用例。有一些功耗低的设备，它们的功能不多，它们需要与 IoT 端点（AWS IoT 服务）通信。我们可以为其生成凭证，允许它们在上线时这样做。有很多……

有几种情况。有一种是企业对消费者，这是一个拥有最终用户的移动应用程序。有一种是企业对企业，你正在为其他企业构建服务，并且你需要在他们……所以有很多用例。我认为有一个与 ALB 的集成。

你将 ALB 置于你的后端前面，然后 ALB 对 Cognito 用户池进行身份验证。因此，与不同的 AWS 服务有很多集成，人们不断发现新的使用方法。但核心能力是它是你的应用程序的前门。

你使用 Cognito 登录，然后你获得一些令牌来保护你的后端，无论你如何构建它。

祝贺 Memento 最近的融资轮和无服务器主题的普遍可用性。Memento 是由 DynamoDB 背后的工程师创建的实时数据平台，他们利用多年运营 AWS 上最流行和最可扩展的服务之一的经验，创建了一套强大的构建块，用于云原生应用程序，例如缓存、存储和发布/订阅。

帮助开发人员安全可靠地为庞大的全球受众提供服务。Memento 可以帮助你加快产品开发和增长，并通过提供这些冗余设计的全托管服务来帮助你降低风险和停机时间。最好的事情是，你只支付你使用的费用。访问 go-memento.co/theburningmonk 获取更多信息。

是的，你提到的用例是允许前端直接访问例如 DynamoDB 表或 S3 对象，而无需 API。我实际上看到 Goiko Asic 使用它来实现他的思维导图应用程序。他告诉我，好吧，是的，如果你不使用 API Gateway 或 Lambda 来执行身份验证之外的任何操作，那么

DynamoDB 已经通过 IAM 完成了身份验证，那么是的，你可以完全避免使用该 API 层，而让前端直接与后端通信。但在极少数情况下，特别是像他这样的专家，因为这感觉非常像一种

高风险高回报的构建应用程序的方法。显然，如果你做错了，这可能会让人们访问他们不应该访问的数据。

但这实际上是一个非常有趣的用例，在我几年前与 Goiko 交谈之前，我从未想过。但是 IoT 的那个，我已经看到很多次了。感觉就像是你想要你的 IoT 设备的唯一，或者主要的方式。我认为有了那个，那个东西叫什么？我认为使用 IoT 服务，你可以做的一件事是……

发出可以嵌入到 IoT 设备中的证书，它们可以使用该证书对认知身份池进行身份验证。在你参与开发的所有这些功能中，有什么特别让你喜欢的吗？我的意思是，我一直从我的后备口袋里拿出来的一个功能是 Cognito 用户池的自定义身份验证流程。似乎无论用例是什么，这似乎都是对任何人的某种解决方案。我知道你已经做过很多关于无密码身份验证等方面的冒险。但是其背后的想法是，每个身份验证基本上都是一个流程

这是我拥有的，然后是一系列挑战。这是我所说的我的身份，这是我拥有的，然后我可以得到它吗？他们说，不，证明这一点，或者这是你的下一个挑战。所以也许像用户名和密码，或者输入我们发送给你的一次性代码。所以我认为当我们在私人测试版中时，

我们为身份验证流程的每个不同组件都有一个单独的 API。如果它是 MFA，我们有一个单独的 API；对于用户名和密码，我们有一个单独的 API。我们看到这只会变成一个巨大的 API 表面区域，这将更难以管理。

我认为我们退后一步，将此身份验证流程提炼成启动身份验证和响应身份验证挑战，以便我们可以支持任何身份验证流程。但也许有人会通过明信片向你发送代码之类的东西。这将支持这一点。我们不需要添加新的 API 来支持这一点。所以我认为……

我们早期意识到的这一点以及我们构建灵活性的方式，在未来随着这些不断发展的身份验证流程的发展中，带来了很多回报。对于 CognitoSync，我已经

很久没有看到任何人使用了，除了玩具项目。你看到有人实际将其用于任何用途吗？除了玩具项目。所以我们肯定在游戏社区中有一些用户用于保存游戏，我们还有一些用户只是试图同步用户偏好，并且

它在 2018 年随着 AppSync 的推出而被弃用。因此，AppSync 具有 GraphQL 等功能，提供了当时在 2014 年 Cognito Sync 构建时根本不存在的更丰富的用例。

所以我们真的开始将人们推向它的继任者 AppSync，它允许你做更丰富的事情，以及你想要做的所有同步的事情。它更像是一个 Firebase 类型的竞争对手，而不是 Cognito Sync。是的。是的，AppSync 也是我最喜欢的服务之一。

说到 Cognito，感觉它已经休眠了很多年了。但最近，他们实际上宣布了一些更新，并解决了一些人们多年来一直抱怨的问题。其中之一是无法自定义访问令牌，因此每个人都必须使用 ID 令牌。也许，首先，

你对这个问题有什么想法吗？因为我知道很多人读过 OfZero 的这篇博客文章，关于为什么不应该使用 ID 令牌。但是当我与 80% 安全团队的几个人交谈时，

至少我得到的反馈是 ID 令牌并非邪恶，它们有合理的用例，但由于某种原因，它们被 OfZero 的那篇博客文章妖魔化了。你对何时使用 ID 令牌，或者是否应该使用 ID 令牌与 API 通信（与使用访问令牌相比）有什么想法吗？

是的，我认为理解这一点的一部分是说我不是身份验证专家。我作为后端开发人员长大，我通过阅读规范等来学习身份验证。所以我不确定我是否真的有强烈的意见，但是

我的角色是制作一些可扩展且安全的东西等等，所以……我认为如果你想了解何时使用 ID 令牌与访问令牌的强烈意见，你应该与对身份验证安全非常兴奋的人交谈，但是……我对它有一些看法，我的意思是

使用 ID 令牌，它可以分散你需要进行授权的许多调用。因此，当你在令牌本身中嵌入关于某人所属组或具有个人资料信息的声明时，这意味着你不需要在你的数据平面中调用某些服务来获取该信息。

这确实使其更轻量级且更具可扩展性。而对于访问令牌，你确实需要调用。我想我并没有，我的意思是，我可以两边都支持。我知道 API Gateway 支持 ID 令牌和访问令牌来保护你的后端。我认为，

就像我觉得我不是在这里讨论何时使用一个而不是另一个或好处的人，我只是知道从我的角度来看，我通常使用 ID 令牌，它们对我来说足够好，我喜欢它们的可扩展性，而且我认为它们对于我的用例来说是安全的

是的，我一直觉得使用 ID 令牌也很舒服。但我偶尔会因为 OfZero 的那篇博客文章而受到抵制。但这没关系。我的意思是，它们可以包含 PII。所以如果你试图隐藏一些 PII，但是我的意思是，只有最终用户应该拥有它们。通常情况下，使用访问令牌，你可以使用访问令牌来访问相同的个人资料。

我没有强烈的意见。我可能很容易被说服。是的，我也是。我也不是身份验证专家。对于 API 来说，就像我说的，如果你有一个访问令牌，你可以调用所有这些 API。通过调用一些 API 来执行与“哦，你的名字是 Yen，我们将使用该信息”非常不同的事情，你可能可以用访问令牌做更多破坏性的事情。是的。

我没有强烈的意见。我可能很容易被说服。是的，我也是。我也不是身份验证专家。对于 API 来说，就像我说的，如果你有一个访问令牌，你可以调用所有这些 API。通过调用一些 API 来执行与“哦，你的名字是 Yen，我们将使用该信息”非常不同的事情，你可能可以用访问令牌做更多破坏性的事情。是的。

好的，在这种情况下，你在 AWS 工作了，就像你说的，15 年。这是很长一段时间。是的，我这里有一个展示。这是我的紫色徽章。这意味着 15 年。是的，对于那些不知道的人来说，当你加入 AWS 时，你会得到第一个黑色徽章，然后是五年，然后是十年，然后你会得到不同颜色的徽章。

是的，我可以对此开个玩笑。所以你从蓝色徽章开始。我对颜色有一些有趣的名称。所以蓝色徽章是你正在溺水的水的颜色。然后五年后的黄色徽章意味着你至少尿过一次裤子。然后红色徽章是红色的，因为它沾满了血。有些是你的，大部分是别人的。

然后紫色徽章是，如果你买不起酒窖，那就说明你做错了。这些是我对徽章颜色的戏谑描述。对。

我无法评论任何高级别的徽章，因为我还没有获得它们。对。但我想说的是，在一个像 AWS 这样的环境中生存需要很大的勇气。

尤其是在构建所有这些大型系统时，如果你做了一件事，做错了，那就很容易惹恼很多人。我听说过一些本来很优秀的工程师无法在 AWS 中取得成功的故事。AWS 非常重视这些领导力原则。那么你会说……

在像 AWS 这样的大型公司取得成功需要做些什么？是的，我认为在 AWS 取得成功有一些技巧。我认为如果我要给加入亚马逊的人一些建议，

我认为最重要的是你处理事情的能力。所以你会得到一个项目，或者你会得到一些需要清理的烂摊子，而你能够以冷静的方式全面地看待它，理解正在发生的事情，理解你拥有的数据，你需要获取的数据，你是否需要添加大量指标，

深入了解到底出了什么问题或需要发生什么，然后以务实的方式思考一下，连接所有点，然后让它消失，就像如果你得到一个项目，它是你的，你拥有它，并且尽你所能做好工作，把所有的点都点上，把所有的线都画好，做这样的事情，而学习如何处理事情的最好方法之一就是观察前辈，我的意思是他们什么都见过，而且……如果你能与一个在那里工作过一段时间的人结对，他们会确切地知道……

对于每个人来说，你应用于遇到的每个问题的领导力原则都是不同的。仅仅是观察一个在第一线工作过一段时间的人，这有点像，如果你观察一个使用 Vim 很长时间的人，或者类似的东西，这几乎是神奇的，他们能够如此快速地通过所有……四处跳跃，看起来……

既令人安慰又混乱，而且不知何故……他们能够做到这一切，但我的意思是，为了充分理解它，你只需要看到它发生几次，并意识到一些不可能的事情实际上是可能的，所以我知道我从那些在那里工作了很长时间的人那里学到了很多东西，我认为当你进来的时候，只是

观察这些事情是如何发生的，因为如果你知道的话，你可以使用很多作弊码。我的意思是，我可以举一个我学到的作弊码的例子，这个例子是我学到的比较晚的，其中有一个非常激烈的面试过程，而标准提升者拥有最终决定权。所以如果标准提升者不喜欢候选人，

而你无法说服标准提升者这是一个好候选人，那么该候选人就不会被录用。我记得有一次我尝试过这个，标准提升者对这个候选人有些事情耿耿于怀。团队中的每个人都认为这是一个很棒的候选人。他们与团队很匹配，他们有很好的资历，但标准提升者耿耿于怀。

我只是让标准提升者说话。在简报的最后，我说，我认为不雇用这个候选人是一个错误。标准提升者说，好吧，还有其他人这么认为吗？然后其他人跳出来说，是的，不雇用这个候选人将是一个完全的错误。然后标准提升者慢慢地……

站在我们这边，这些都是很小的事情，但这些是你认为你不能做的事情，直到你有经验，这些是你甚至不敢尝试的事情，所以……例如，你永远不会因为数据而出错，所以如果你

如果你处于一种棘手的情况，也许出了什么问题，发生了一个运营事件，你带来了你能带来的所有数据……如果你有数据来支持所发生的事情，并且你理解发生了什么，并且你知道……

所有出错的地方以及你需要修复的所有区域，没有人会对你大加指责。所以你只需要准备好应对这些情况。如果你没有准备，或者你超过了你所知道的范围，所以你在讨论运营事件时进入推测的领域，你将立即受到攻击。所以如果你不知道，

就说你不知道，你会发现的。这就是你降低房间温度的方式。但如果你说，也许是这样，那么房间里所有聪明的人都会立即告诉你为什么不是那样。绝对的，另一个非常有效的策略是专注于三件事。

所以你总是需要非常敏锐的重点，无论你是在试图解决一些运营问题还是类似的事情。你需要专注于三件事，你需要每天都一点点地努力，并继续取得进展。只要你

专注于某事，并且你可以始终展示你所专注的内容以及你取得的进展，你总是会比你无法展示时做得更好，所以这些是我认为的一些事情，另一件明智的选择是，如果你得到任何亚马逊股票，请保留它

至于获取数据，例如，你前面提到过推出新服务。例如，对于 Cognito 的新服务或新功能，你将如何收集数据？因为这是一个你还没有的功能。你无法真正证明人们一定会使用它。那么你将如何处理这样的事情呢？

是的。所以对于一个新功能来说，这有点像与客户交谈，了解他们的问题所在。我的意思是，客户会告诉你他们想要什么，但由你来决定他们真正需要什么。他们可能会描述他们想要什么，这与你实际上应该构建的东西不同。所以有很多

产品经理会联系客户并进行访谈。作为开发人员，与客户交谈也很棒，找出他们的痛点。通常情况下，你已经知道他们的痛点是什么，但有时你可以通过这种方式获得信号。我认为

另一件事就是尽可能地对所有东西进行检测，这种想法是拥有非常广泛的日志事件，这样当你需要回答一个临时的问题时，这是一个你需要回答的全新事物，你可以去你的日志中编写一个查询，它会给你

至少你需要回答你的问题的第一部分数据，所以我们肯定是从客户那里倒着工作的，我们尝试，我们尝试使用我们的数据来支持我们已经做出的假设，然后通常有一个迭代的

周期，通常会有一个私人测试版，我们邀请了一些客户来试用并获得反馈，以确保没有清除问题，然后我们进入公开测试版，然后是通用可用性，所以在设计阶段肯定有很多想法，我们

与负责人讨论设计，看看他们是否见过类似的东西，以及我们的陷阱是什么，这听起来对吗？所以有很多验证，我们尽量用实际数据来支持它，而不是轶事客户评论或类似的东西。你必须做的事情清单来启动一个功能会越来越长。但是……

这是可能的。我的意思是，没有人能在三个月内像我们在2014年那样启动AWS服务，包括所有必要的审查和签字等等。你需要启动你的CloudFormation支持。你不能不启动CloudFormation就启动。所以所有这些小事情，CloudTrail，CloudFormation，都需要时间。它们现在是必需的。你不能事后才做。

我想也许一个例外是S3的事情，S3会因为无效或未经授权的请求而向你收费。这件事很快就扭转过来了，但我猜这可能是一个特例，因为它是一个很大的公众哗然。所以杰夫·巴尔和很多人立刻就跳进来了。

是的，我的意思是安全是亚马逊的零号工作，所以我会认为这属于高风险的安全领域，然后每个人都会团结起来完成这项工作。所以，你得到了一个非常

嗯，聪明、勤奋和聪明的公司支持你，像这样的事情，你就会有很多这样的例子，如果需要快速完成，就会快速完成，人们会找到方法，所以

关于你在AWS的时间还有一件事，这是你之前提到的，好吧，录音后，你提到了这个欢迎回来伙伴的体验，我从未听说过。这是什么？这是一种完美世界的描述。所以当我考虑开发者体验时，

这就是我脑海中想到的事情，也就是欢迎回来伙伴的体验。所以，通常当你与电脑互动时，它们会有这种健忘症。所以他们并不真正知道你是谁或你想做什么，他们也不会真正帮助你。但是当你到朋友家时，他们不会问你你的用户名是什么，你的密码是什么。

诸如此类的事情。他们说，欢迎回来，伙计。这是你最喜欢的饮料。你玩得很开心。我认为当你构建开发者体验时，你的工作就是

收集所有这些上下文并使用它，以便你可以提供这种欢迎体验，例如，如果你正在与语音助手对话，并且

如果你说关灯，它会问你你想关哪个房间的灯？但这在与另一个人交谈时是不会发生的。对。但是如果你和一个人在同一个房间里，你说，嘿，你能关灯吗？让我们关灯吧。没有来回。没有输入格式，例如。

哦，你说的是房间，但我并没有真正理解。你能用不同的格式重新表达一下吗？诸如此类的事情？所以这就是我追求的，就像终极开发者体验一样。我认为人工智能在使用所有可用的上下文来使这个过程更轻松方面取得了一些不错的进展。我想我之前发过一条关于这个的推文。

身份验证的目标是为你的最终用户提供轻松的身份验证，并为你的对手提供不可能的身份验证，我们目前处于中间状态，登录对你来说有点令人沮丧，对吧，人类交互登录，他们知道你是谁，他们只是让你进去，但是如果

不是你，那么他们，我的意思是，他们不像电脑那样安全，你可能可以用甜言蜜语哄骗你进去。但是我的意思是，我非常沮丧的一件事是在亚马逊，我会第二天回到我的办公桌，晚上会发生一些事情，而不是让我能够继续我之前的工作，

也许有人在某个角落部署了一些东西，然后一些东西坏了，所以我必须花很多时间试图弄清楚，我想做x，但我必须做所有这些热身，我必须像，好吧，发生了什么，为什么我不能这样做，谁改变了什么，所以欢迎回来伙伴体验的想法是让它成为这样，就像

就像拜访朋友一样，但你直接进入重要的内容，你不会因为输入电脑应该已经知道的所有这些东西而被非人性化。这就是这个概念。这正是我在Speed Run背后玩弄的想法之一，让它成为这样，它，它，

它就像当你试图做某事时，它实际上帮助你做这件事，而不是妨碍你并向你索要你已经知道的大量东西。

好的。你的意思是，从概念上讲，我理解你不仅想要个性化体验，而且还要了解上下文，你刚才进行的对话的Chat GPT。你不需要每次都重复很多东西。所以你有什么可以快速演示并展示你一直在做的工作，你如何将这个想法转化为实践吗？

是的，让我在这里分享我的屏幕，我将向你展示一些东西。让我把这个移开。你现在能看到我的屏幕吗？是的，我能看到。好的。是的，让我向你展示一下。这里的想法是，当你需要做某事时，你希望它尽可能轻松。并且

每个软件开发团队都有一些文档。通常，这些文档处于某种程度的腐烂状态，这取决于上次修改的时间、上次使用的时间以及人们保持文档更新的务实程度。

它们可能包含错误，例如，某些事情可能已经改变了。所以Speed Run的想法是让你的文档真正帮助你做一些事情，让它们始终保持最新，而不是仅仅告诉你该怎么做。因为如果它只是告诉你该怎么做，那么人们不会总是遵循文档。他们会跳过步骤。他们会犯错误，诸如此类的事情。所以Speed Run的想法是让

你可以将足够的上下文放入你的文档中，以便你可以单击执行文档中所说的内容，并且它们对你来说实际上是有用的，这样人们就会不断更新它们，而不是随着时间的推移而逐渐萎缩。所以我们在这里看到的是一个普通的GitHub wiki，Speed Run技术运行在其之上。它知道

我所有帐户和我的服务正在运行的区域。我在这里运行两个区域。我在这里有俄勒冈州和俄亥俄州。工具栏只需让你快速访问。所以如果我想进入我的IAM帐户控制台，它会为我获取凭据并将我联合到正确位置的控制台中，以便我可以在此处执行操作。看起来我

我已经真正锁定了这些特定帐户，这样你就无法在我的AWS帐户中乱搞，因为这是一个你甚至可以运行的现场演示。无论如何，让我们快速概述一下工具栏。所以你有了你正在查看的最后GitHub问题。所以你可以快速返回到这些问题，并且……

像这里的设置一样，你可以为你自己配置所有设置，你的个人帐户等等，所以让我们进入Speed Run真正做的事情，所以Speed Run允许你将东西转储到你的文档中，带有一点markdown，以便

如果你只是运行一个CloudWatch查询，现在你想让你的团队中的每个人都可以运行这个CloudWatch查询。所以假设你有一些操作任务需要运行此查询，一些临时的事情。你需要查找某个客户的帐户，找出某些事情并跟进某些事情。你放在文档上的唯一代码，这个太小了吗？我可以把它放大一点。

是我想运行一个CloudWatch insights查询。我可以看到你很好。这是我想运行的查询。这就是我放入文档中的全部内容。这为你提供了一个按钮，它将获取此处的上下文。所以在这个服务中，在这个区域中，它将构建精确的命令并运行它，以便我现在使用正确的日志组位于美国西部2或俄勒冈州。

使用我需要运行的查询来获取我的答案。所以我只需单击“运行查询”，我就会在这里得到我的答案。它可以获取用户输入。所以，通常当你做临时的事情时，仅仅有一个预先准备好的查询是不够的，你需要来自用户的某些信息。所以这里有一个类似的例子。

提示用户输入，你用一堆波浪线包围提示。所以在这里，我想提示收集的岩石数量。这是一种更高级的用户输入，它是一个类型选择。所以它是一个带有这些选项的下拉菜单。我只是将那种markdown直接嵌入到我的查询中。所以当我单击这个时，它会变成什么，

有多少收集的岩石你想看？我有这个，我得到了一个漂亮的用户界面，我可以提前输入，查找东西，我单击确定。所以这是一种围绕AWS控制台的包装器，有时使用起来有点费解。现在使用起来容易多了。所以现在你可以看到它已经用20构建了查询。所以当我单击这个时，我得到了我的结果。

伙计，这感觉像是魔术。是的。所以，你可以根据自己的需要使用它。就像你一样，所以这是一种围绕

这是一种围绕控制台的包装器。你可以做很多事情。例如，你现在可以从你的文档中直接调用Lambda。所以如果你有一些需要调用Lambda的增值内容，这里有一个简单的例子。所以我想调用Lambda。这是我的函数的名称。然后我想给它这个JSON。所以我有一个名字。

我将提示你输入你的姓名，默认情况下，姓名将是Samuel Jackson。所以当我单击这个时，你可以在这里看到它已将名称默认为Samuel Jackson。我可以运行JavaScript代码，所以我可以做任何我想要的格式化。也许它是一个日期，或者我需要

从一种格式转换为另一种格式，无论是什么。但本质上，我现在有了这个UI，我输入这个，我单击确定。它在这里由Lambda调用。你可以看到它复制了剪贴板中的某些内容。所以如果我去粘贴它在这里写的内容。

“来自Lambda和美国西部2的Burning Monk你好。”你可以在这里看到我不担心登录控制台或获取凭据或做任何类似的事情。我只是说，“看，我想在美国西部2运行这个。这是我的输入。你做剩下的。”对吧？它会为我处理剩下的事情。这个稍微高级一点。这个正在调用Lambda函数URL。

我实际上可以向你展示一些幕后发生的事情，所以这就是你运行JavaScript的方式，你可以使用这个美元和花括号语法引用变量，这意味着我已经在某个地方定义了lambda函数URL，所以让我们向下看，我将在这里向你展示，所以这是这个页面的整个配置

只是一些JSON。我已经定义了很多东西。我的角色是演示角色。这是我所有的服务。我有这个Dekacorn服务，你可以在不同的级别定义东西。我有，好的，这是S3存储桶名称，它基于我当前所在的区域。这是区域。所以在美国西部2，这是

变量将被美国西部2替换，诸如此类的事情。但是你可以看到我已经在这里为这个帐户定义了函数URL，这样每当我使用它时，我不需要不断输入函数URL是什么，它只是替换。我回到这里。它根据当前上下文用它替换这个。

好的，它从你当前登录的会话中的当前上下文中获取区域，对吧？如果你查看调试信息，你可以看到它能够将存储桶名称解析为美国西部2。如果我继续并将此更改为美国东部2，对吧，这现在是美国东部2。

所以这向你展示了一些它能够根据你的当前上下文解析的内容的错误信息。你可以覆盖。你可以在这里看到我正在定义函数名称。所以如果我想更改角色，我会说role=my special role或其他什么。这将仅为此特定块覆盖它。

所以你可以在任何级别定义任何东西。你可以将你的配置转录到另一个页面上，这样你就不会到处重复它。那里有一些层次结构。这个，好吧，让我调用这个。所以这个是一个有点愚蠢的演示，假设你有一个暖坚果分配器。

所以你去休息室，然后得到一些暖坚果。在这里我可以指定我是否想要暖坚果或冷坚果。我单击确定。它将调用我的Lambda端点。然后如果我在这里粘贴它，它知道我是谁。所以它是，嘿，紫色，这是我的GitHub登录名。这是来自该区域的一些暖坚果。它给了我一堆坚果。

如果我再次运行它，它会给我另一组。我会再做一次。但它记住我之前输入的所有内容。好的，所以你可以在这里看到，当它放回去时，它有点不同。然后这里有一个关于调用步骤函数的有趣内容。所以这个……

有一个汤销售员，你必须对他好。美国有一部情景喜剧叫做《宋飞正传》。有一集是关于一个脾气暴躁的店主，你必须礼貌地问他，否则他不会给你任何汤。所以这是，嘿，是的，如果你的头发看起来不错，我可以喝一碗蛤蜊浓汤吗？所以这将启动一个带有该输入的步骤函数。所以这里……

它使用识别或理解（我指的是理解）对我说的话进行了一些情感分析，并决定我是否礼貌地询问。但是如果我回去说，你的头发看起来很糟糕，你可以在这里看到，没有汤，但是它不喜欢那样。但是同样，就像

我基本上在我的页面上什么也没放，但我得到了这个非常强大的东西，它对于构建命令行非常有用。你可以嵌入iframe，所以你可以将代码笔或YouTube视频嵌入到你的内容中。它像模板一样溢出。

它运行一些JavaScript来获取当前日期。我不知道。好吧，我真正想说的是，我在AWS上构建了类似的东西来进行操作，但总有一些事情在发生。这是我将某些东西扔进wiki并使我的团队能够立即执行我刚才所做的事情的最简单方法。

所以我可以在一两分钟内构建一个Speed Run块。然后我的团队中的每个人都立即拥有这个工具来帮助他们做一些事情。它是一种摆脱困境和进行操作的强大催化剂。所以这是一种，我正在基于GitHub和其他一些在亚马逊之外可用的技术重新构建它。我做得很开心。所以，是的。

有什么问题吗？是的，因为在我看来，如果有人要采用retool的想法，但不是构建自定义UI组件，而是用Markdown来做。特别是如果你的所有集成主要与你的AWS控制台集成。是的，我的意思是，你也可以调用命令行。让我向你展示它是如何工作的。

DynamoDB。所以，例如，你可以像在控制台中打开它一样。这可能是你想要与之交互的方式。所以这是在Dynamo表中查找歌曲歌词的出现次数。但是你也可以从命令行运行它。所以你永远不会想把它交给你的PM并说，运行这个，因为他们会搞砸一些事情。但是你可以给他们

基本上，我已经获取了你将要运行的命令以及它需要的键。所以我只是在这里复制，你单击确定。如果他们对该角色有权限，它会将该命令与获取凭据的命令一起包装。让我在这里放大一点。所以我有一个命令来调用我的端点以获取凭据并使用这些凭据设置你的命令行。然后……

调用AWS CLI来获取你的答案。所以这是输出2，这是……所以你可以基本上，如果你非常擅长单行代码等等，你可以将它们扔进你的文档中，这将使它们对所有人可用。它将用UI包装它，并使其对团队中的其他人来说更容易使用。所以……

然后你也不需要担心你的，如果你正在进行直播，不需要担心你的凭据泄露或任何类似的事情，因为这些都是临时凭据。你永远不会在任何地方看到任何凭据。所以它对于这个用例也很有趣。

酷。这看起来非常好。我甚至在考虑将这个用于我的一些研讨会，因为我经常发现人们难以遵循说明。就像你说的那样，我的许多研讨会内容只是说明步骤，就像一个剧本一样。有时人们……

在他们运行的命令以及他们运行的顺序方面犯错误。这感觉就像，好吧，这可以使生活轻松得多。我可以有一个步骤说，一旦你做出了这些更改，就可以部署或点击此命令来运行查询，是的，除了剧本和所有这些之外，我还想到了很多用例，但即使只是为了培训。

是的，还有一个更有趣的用例。我不知道你是否使用Identity Center。让我，这是一个我最近创建的用例。但是如果你正在使用Identity Center，让我们看看，我在这里可以访问什么？让我们只转到CloudWatch日志或类似的东西。所以它会在控制台中给你这个小Speed Run图标。

它的作用是构建到此特定页面的深层链接。所以如果你在控制台中的某个地方，并且想要共享你在特定帐户和特定角色中的位置，你只需单击这个，这个，它将构建你可以与他人共享的确切链接。然后他们不需要安装任何东西。他们可以准确地接上你所在的位置

所以这与我的Speed Run凭据代理和Identity Center凭据代理都兼容。它会自动检测你的登录方式并为你提供该链接。这真的很酷。所以如果有人想今天尝试一下，他们去哪里？

这是现在就可以下载和安装的东西吗？是的，它是开源的。如果你访问speedrun.cc，它会带你到我的网站，我们会向你大致介绍它是什么以及它能做什么。我认为你可能提到我可以为我的客户提供这个。所以

我会说，在这一点上，它有点粗糙。所以你需要安装Tamper Monkey，并且你需要安装此脚本才能使其工作。我仍在努力弄清楚产品市场适应性在哪里，以及我是否需要将其重新创建为可在任何网站上运行的独立脚本。所以任何地方都像

就像你的网站一样，这样就没有人需要安装任何东西，它开箱即用。因为现在它有点依赖于GitHub的wiki功能或markdown功能。你需要安装此脚本才能看到这些Speed Run块并将它们全部连接起来。

但我正在努力使其无需安装任何东西，它开箱即用。所以如果你有兴趣这样做，这是一个可以与我讨论的事情。就像我在AWS时一样，安装Tamper Bucky脚本不是问题，但我发现……

在AWS之外的阻力要大得多。这是什么东西？就像我一样，它看起来真的很酷，但我并不特别舒服。所以如果你想进一步讨论，我很高兴看到你的用例是什么。我确实在做研讨会或演示时使用过它，这样人们就可以单击、单击、单击并快速执行某些操作来进行设置。但是是的，

是的，我认为入门时存在一些摩擦，我很想摆脱这种摩擦。

好的，我想这就是你必须考虑如何将其产品化和打包，以便使用该工具的开发者体验更好。但是如果它依赖于GitHub Markdown，那么是否可以依赖，好吧，基本上获取它，然后使其适用于Bitbucket和其他平台？

获取提供商，如果它们都是以某种方式标记的吗？-是的，我的意思是，这项技术只需要markdown。所以它正在寻找以某种方式格式化的代码块，然后它能够将所有内容连接起来。所以我可以让它在任何markdown之上工作。我首先选择GitHub和AWS是因为我认为每个人都会在那里，每个人都在使用GitHub。

它也适用于自述文件之类的东西。所以让我向你展示，让我转到我的存储库的自述文件。这是我的网站。你可以在这里看到顶部，我可以切换我的生产和数据端点，然后它将构建我需要部署的确切命令。

所以这是一种将工具直接构建到你的文档中的好方法，以便使其对你的最终用户有所用吗？是的，这很酷。

不再需要从markdown复制，然后在控制台或终端中运行，只需直接从那里运行即可。是的，它是一种层。就像你说的那样，它不太像retool。它有点介于ClickOps和IAC之间，它试图兼顾两者的优点，使其易于使用，并且

提供一些防护措施，这样你就不会一直自讨苦吃。这就是我目前所处的位置，以及我想要达到的目标，即使其尽可能容易，而无需学习太多新的语言，并且必须在可能消失的其他人平台中进行部署和重建所有内容。我只是想用Markdown。对。

是的，这个，是的，我没有意识到你一直在做这个。但是这个，是的，这看起来非常有趣。我认为，好吧，肯定的是，我将自己尝试一下，因为我有一些事情，我认为这可能非常有用，特别是对于我的一些副项目，你知道，我只是想进行部署或想尝试一些东西，然后只是，你知道，使用CloudWatch日志内部查询一些日志消息等等，这，你知道，

同样，在控制台中需要很多点击才能到达我需要去的地方。而我可以将它们放入我的markdown和我的存储库中，这将直接带我到那里并运行查询。是的，我用它来保存我曾经做过的所有事情的痕迹，这样如果我需要回到它，我可以很容易地复制它。仅仅是它记住你上次输入的内容这一事实。

这样你就可以继续你之前的工作。就像你正在迭代某些东西一样，哦，我上次搞砸了，但是表单已经用你上次输入的内容填写好了，这样你就不需要每次都从头开始，我认为这真的很有帮助。

是的，这看起来非常有趣。我想当你越来越接近将它产品化，使其更容易安装时，我们应该可能再进行一次网络研讨会，并在你达到这一点后对它进行适当的演示。是的，我的意思是，我在过去一年中实现了100%的正常运行时间。它已经准备好投入生产了，但我认为它目前更适合开发者，而不是

对于开发者的最终用户。所以如果你是一个开发者，并且对正在发生的事情感到满意，那么它已经准备好为你使用了。它已经为你准备好了很长一段时间，但我正在努力弄清楚如何打包它，以便它也可以被你的最终用户使用，而无需任何安装或任何类似的东西。所以我想我每天都用它。我，

但我很高兴地说，我已经实现了100%的正常运行时间。使用它进行你自己的开发类型的工作没有任何问题。

我想我考虑更多的是，这对你来说没那么重要。我认为你之前也提到过，你可以让你的工程经理或其他人来做这件事，但是要运行脚本，他们仍然必须安装speed run。对于开发者来说，重新安装所有这些不同的东西可能没问题，但是如果你想让你的经理（技术水平较低或不太上手）更容易地安装speed run，而不用摆弄所有这些脚本，可能会更容易一些。

是的，现在它是一次性设置，但是，我的意思是，我真的很想让它做到零步骤就能开始，你只需要访问网站，它就能工作。好的。但这看起来真的很令人兴奋。谢谢你给我看这个。是的。

好的，我们已经超时了。是的，非常感谢David来到节目中，向我展示了speed run，也向我们介绍了Cognito的背景故事。在我们结束之前，你还有什么想告诉我们，告诉听众的吗？如果他们想了解更多关于你正在做的工作的信息？我也会在下面留下speed run的链接。在你走之前还有什么想分享的吗？

是的，我的意思是，在同一个网站上，我有一个博客，我尝试在那里发布一些我发现的关于无服务器的有趣的东西，如果我没有付费墙或对使用我的产品有任何期望的话。所以我尝试寻找一些与我正在做的工作有点正交的有趣的事情。我谈论冷启动。我谈论

使用边缘函数，我在这里谈论一些有趣的事情，所以如果你对此感兴趣，这里有一些有趣的内容，我还想感谢Jan给我机会参加你的播客，这是我的第一个播客，

我相信这将是许多播客中的第一个。顺便说一句，我已经阅读了你最近的很多博客文章。我真的很喜欢它们，你一直在谈论的内容包括CloudFront函数和函数URL。所以，谢谢你分享所有这些东西。我很高兴你没有在Medium上这样做，因为Medium的付费墙一直让我抓狂。

是的，所以我的意思是，其中一些内容也类似于500级的内容，它们只是我脑海中的一些意识流，所以我也很乐意帮助任何人，如果他们对一些我做过的更奇特的事情有任何疑问，我很乐意解释，我知道很多人在LinkedIn上联系我，询问后续问题等等，所以

我不是想卖给你任何东西，我想帮忙，我真的很喜欢我在AWS中所处的领域，我希望我能和你一起学习，并且能够以任何方式帮助你，所以

好的，我也会在下面的描述中留下David的联系方式，这样如果你们对speed run或David一直在写博客的任何事情有任何后续问题，你们可以亲自去问他。至少在社交媒体上。是的，所以David，再次非常感谢你。我希望你会参加reInvent。我期待着亲自见到你。

是的，我还需要买票，但我已经订好了酒店。今年我会参加GitHub Universe和reInvent。我想这将是我第六次参加reInvent了。好的。在这种情况下，我期待着在reInvent期间见到你。感谢大家收听本期节目。我希望下次也能见到你们。保重。好的。干杯，Yan。干杯，各位。再见。

感谢Memento对本期节目的支持。要了解更多关于他们的实时数据平台以及他们如何帮助你加快产品开发的信息，请访问gomemento.co/theburningmonk了解更多信息。

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