这更多是一个悬而未决的问题，我只希望有任何意见和建议。我想到了AWS，但它也可能与其他云提供商有关。
我想提供IaaC解决方案，该解决方案将易于维护并满足现代无服务器架构的所有要求。 Terraform是定义基础结构的好工具，拥有许多官方资源和社区的稳定支持。我真的很喜欢它的语法和模块的整个概念。但是，这对于使用Lambdas来说是非常糟糕的。这也引发了另一个问题：代码更改是否应该使用与基础结构更改相同的流程来部署？在代码和基础架构之间划清界限的地方是什么？
另一方面，无服务器框架允许Lambda的超级轻松开发和部署。在资源使用方面，它受到了强烈的质疑，但它具有许多值得使用的现成功能。它实际上不应用于定义整个基础结构。
我当前的方法是使用Terraform定义任何共享资源，并使用Serverless定义任何与域相关的资源。在这里，我还有一个与之前的问题有关的问题：部署依赖性。一个简单的场景：Lambda.1将用户添加到Cognito作为触发器的Lambda.2（共享资源）中。我必须创建一个用于管理部署顺序的自定义解决方案（{Lambda.2必须首先部署，等等）。可以将无服务器框架部署挂接到Terraform中，然后再将其挂起：代码部署应与基础架构部署混在一起吗？
答案 0 :(得分：7)
完全有可能将两者混合，而我不得不这样做几次。最终看起来比看起来简单。
首先，如果在开发微服务时考虑使用无服务器框架做什么（没有相关的基础架构管理负担），那就朝着正确的方向迈出了一步。然后，您可以做的是确定是否在微服务中定义了使该微服务在内部工作所需的所有内容，并将其作为serverless.yml中服务配置的一部分，而不论是DynamoDB表，Auth0集成，Kinesis流，SQS ，SNS，分配给功能的IAM权限等。请将所有内容定义为该微服务的一部分。不需要地形。
现在考虑一下与其他微服务进行更广泛的交互所需要的内容。它们对于该服务的内部运营并不重要，但对于集成到组织的其他基础架构中则至关重要。这包括诸如由无服务器框架服务用于部署到CloudFormation中的部署IAM角色，必须在多个服务和资源之间共享的关系数据库，网络元素（VPC，安全组等），诸如ElasticSearch和Redis之类的整体集群。 。所有这些元素都是无服务器框架之外定义的理想选择，并且可以与Terraform一起很好地工作。
任何资源都可以根据需要连接到这些Terraform定义的资源，与硬关联（例如从API网关端点触发的Lambda函数）不同。
希望有帮助