何时使用terraform vs无服务器框架来部署AWS lambdas和周围的资源



使用无服务器部署AWS lambdas时,可以创建AWS资源。然而,现在我开始使用Terraform来开发资源,我不确定应该通过Terraform文件和无服务器来定义什么资源。

回答可能有点晚,但我最近有一些经验,可以分享一下这个主题。

我曾使用Serverless Framework为一位客户开发应用程序。客户已经有了一个中间件团队,他们有自己的方式来管理与基础设施相关的AWS资源。我有一个类似的问题:我应该在我的无服务器项目中投入哪些AWS资源?

在第一次尝试中,我使用Serverless Framework创建VPC和网络以及lambda函数。这个解决方案的问题是,我的项目与中间件团队的工作方式有很多冲突。他们有一个中心文档来跟踪子网和IP地址。他们为整个组织提供了一个单一的互联网、NAT和VPN网关,其他VPN必须通过传输网关连接到该网关。他们使用第三方软件来管理防火墙规则。等等。我不得不多次修改我的代码,以符合他们的网络先决条件。

第二次尝试,我在我的无服务器项目中只放了Lambda函数和一些东西,其他东西,如DynamoDB表、SNS、SQS、S3、IAM角色、安全组、VPC等,都是由中间件团队现有的IT请求流程预先提供的,并将参考ID放在我的配置中。这个解决方案出现了一个新问题:随着应用程序的增长,新的AWS资源(如DynamoDB表)一直都是必需的,并且供应计划应该与开发周期保持一致。IT请求过程通常与开发周期不同步。由于所需AWS资源的供应悬而未决,该项目被推迟。但要提到的是,资源规范通常会随着我们在开发过程中发现的更多而发生变化。发出另一个IT请求来更改规范会使流程变得异常糟糕。

从这次经历中,我学到了将";应用相关资源";从";与资源有关的基础设施";。将一个混合到另一个中会导致上述问题。

对我来说,有效的办法是不要把网络问题放在一个没有服务器的项目中。相反,通过其他方式预先配置这些资源,例如在单独的项目中使用Terraform或手动配置,并将它们的参考ID放入无服务器项目的配置中。

对于无服务器项目中应该包含的资源,对我来说,最简单的列表通常是Lambda函数、DynamoDB表、SNS主题、SQS队列和CloudWatch事件(EventBridge)。

我通常从这些假人开始,然后开始分析需求,看看我的应用程序在增长过程中是否需要其他类型的资源。将这些资源添加到应用程序相关列表中,并与中间件、架构师和安全团队等相关方进行讨论,以确定列表中的所有资源是否都可以在无服务器框架项目中进行控制。

首先,您可以在https://serverless.com/learn/comparisons/页

事实上,你可以选择其中一个,也可以同时使用它们,因为它们在技术上并不互斥,一个关注一件事,另一个关注在类似的问题空间中解决另一件事——但不是同一个问题等等。选择哪一个取决于很多因素。

基本思路可能是这样的:

当您想专注于无服务器应用程序相关的资源时,您可能会考虑使用无服务器框架(serverless.yml)

但是,如果你想专注于定义成熟的基础设施或更传统风格的云基础设施(即自己定义网络、服务器、存储、负载均衡器等),你可能会考虑使用Terraform。

最好的方法是进行实验,每次只需选择其中一个进行实验。然后,你会发现什么适合你的特定任务,什么让你的自我变得更容易。

我认为这是一个很难回答的问题,因为它取决于许多因素,比如公司的内部结构。

根据经验,我认为只有无服务器服务使用的每个资源都应该在serverless.yml文件中定义,共享资源应该使用terraform(或其他技术)项目来定义。我以前用过这个近似,它很好用。

Yan Cui有一篇关于共享代码和基础设施的好文章(https://hackernoon.com/aws-lambda-how-best-to-manage-shared-code-and-shared-infrastructure-827bed395eb7)。

最新更新