在我与Ben Kehoe在现实世界的 Serverless 播客上的最后一次对话中，他说了一些深刻的话，从那以后就一直困扰着我。现在我准备用这个脑虫感染你！不客气;-）

关于基础设施从代码的趋势，Ben 说：

“我认为从代码开始的基础设施在所有方面都是错误的。我认为我们不应该称之为基础设施...（跳过）...当我们谈论业务逻辑时，我们忽略了业务逻辑存在于非通用编程语言中。选择在体系结构中使用 SQS 队列是一项业务逻辑决策。这是说我需要坚持这个正在传递的信息......（跳过）...同样，我想说的是，最低特权策略是业务逻辑，因为在授权决策中选择重要和无关紧要的内容取决于您正在执行的业务案例......这是业务逻辑的定义?—?特定于您正在解决的问题的不可简化的复杂性。

正如 Ben 所指出的，选择一个服务 （SQS） 而不是另一个服务 （SNS） 取决于业务需求，应用程序中的授权决策也是如此。这种看待 Serverless 架构的角度确实模糊了基础结构和业务逻辑之间的界限。

在服务器应用程序中，您将代码部署到某种“服务器”（虚拟机或容器）上。通常，我们还会将其他软件（例如数据库）部署到这些服务器上。在这种情况下，很容易区分基础结构和业务逻辑。

在与 AWS 的主要交互是“将软件部署到服务器上”的世界中，AWS 资源是“基础设施”的同义词是可以理解的。毕竟，您没有使用 AWS 提供的本机服务，而只是使用 AWS 的基础设施即服务部分。

这种看待AWS的方式已经延续到 Serverless 领域。我们用于开发应用程序的工具被称为“基础结构即代码”（IaC），这一事实进一步强化了这一观点。我们使用这些 IaC 工具创建的任何 AWS 资源都是“基础设施”。

但正如 Ben 指出的那样，我们做出的许多架构决策都是特定于我们的业务的，并由我们的业务需求决定。我们使用哪种消息传递服务，我们是使用EventBridge还是SNS或Kinesis？我们如何将它们集成在一起，是编写 Lambda 函数还是使用直接服务集成？谁可以访问系统，他们可以执行哪些操作？

您可以通过编写自定义 Lambda 函数或让 API 网关直接访问 DynamoDB 来实施 CRUD 终端节点。一个涉及自定义代码，另一个仅涉及首选 IaC 工具中的几行配置。那么，一个算作业务逻辑，另一个算作基础设施吗？即使两者的结果相同？

如果您使用使用通用语言而不是 YML 的 IaC 工具，该怎么办？“在YML中声明”是“基础设施”的定义吗？只有当某些内容包含自定义代码而不是“配置”时，它才算作“业务逻辑”吗？

很长一段时间以来，在 Serverless 环境中谈论基础设施时，我都感到这种尴尬。因为我并不总是清楚基础设施在哪里停止，业务逻辑在哪里开始。和本谈过之后，我还是不确定！但我敢肯定，这种区别并不像我们想象的那么明确，我们不应该通过基础设施的视角来看待AWS资源。

在 Serverless 世界中，我们希望利用云来处理尽可能多的无差别繁重工作。这通常转化为使用服务，而不是编写自定义代码。我们如何配置这些资源以及要求它们执行的操作特定于我们要解决的业务问题。因此，它们与我们编写的任何自定义代码一样，都是我们业务逻辑的一部分。

所以本说服了我，但你怎么看？您是否同意或不同意，或者您认为我们应该以完全不同的眼光看待 Serverless ？

让我知道，我很好奇。