3 ms·

The simplest HTTP API example is https://github.com/nsriram/lambda-the-terraform-way/tree/master/samples/12 https://github.com/nsriram/lambda-the-terraform-way/

by hendry 6y ago

The simplest HTTP API example is https://github.com/nsriram/lambda-the-terraform-way/tree/master/samples/12 https://github.com/nsriram/lambda-the-terraform-way/tree/mas... is about 66 LOC of terraform. But wait, it uses lambda-role (12 LOC), lambda (27 LOC), api-gateway (47 LOC) & api-gateway-lambda-integration (40 LOC). So 66+12+27+47+40=192 of terraform in a BUNCH of files. Compare that to 47 LOC of verbose AWS SAM YAML: https://github.com/kaihendry/count/blob/sam/template.yml https://github.com/kaihendry/count/blob/sam/template.yml All in one file.

raffraffraff 6y ago
Is SAM itself the end game or does it create some other code (like Cloudformation)? The reason I'd be reluctant to use it without thoroughly being it is that I don't like using any 3rd party monster suite of modules. I've been bitten by that a few times. You're at the mercy of the 3rd party to continue updating and supporting the modules. On top of that, it may not support a particular user case you want to implement. And it's almost worse if it does, because that likely means that it's no longer a simple wrapper around raw terraform resources, but a huge complex beast. In this case, I don't think the author necessarily expects the user to directly user his code. It is a set of examples. The modules themselves are very simple (really just one or two raw resources with vars and outputs)
- deleted 6y ago
  [deleted]
- oblio 6y ago
  SAM is a tool created by AWS. It's a set of custom resources plus some CloudFormation macros that expand to CloudFormation templates. It's also a bunch of scripts and utilities that help with the packaging and deployment. At the end of the day you can use it to generate the final CloudFormation template and run that manually, if you want.
deleted 6y ago
[deleted]
_0o6v 6y ago
Comparing SAM and Terraform is like comparing apples and oranges. Comparing Terraform to CloudFormation is more appropriate, and Terraform wins in terms of verbosity there every time. SAM generates CloudFormation templates/stacks, which create your AWS resources. Serverless generates CloudFormation templates/stacks, which create your AWS resources. Related: I wouldn't recommend deploying raw lambda's without a framework. The development workflow really sucks without one. Use SAM or Serverless.
- nuker 6y ago
  > Comparing Terraform to CloudFormation is more appropriate, and Terraform wins in terms of verbosity there every time. Nope.
simo7 6y ago
Problem with SAM is having to deal with one more tool. But also, maybe even important, it makes things less transparent. I want to be able to refer to the original CloudFormation docs (even when using Terraform) without "translating" every time.
pgroudas 6y ago
I agree that using SAM can be convenient for standalone lambda functions. However, in the context of a larger AWS configuration, where your integration points are already in defined in terraform, the cost of using SAM for these is breaking the invariant that "all our AWS resources are defined in _TOOL_ (in this case, _TOOL_ is terraform). The verbosity is frustrating, but largely ignorable. Having to go back to string references of AWS references defined in different sources of truth is a maintenance nightmare, IMO

by hendry 6y ago

raffraffraff 6y ago

Is SAM itself the end game or does it create some other code (like Cloudformation)? The reason I'd be reluctant to use it without thoroughly being it is that I don't like using any 3rd party monster suite of modules. I've been bitten by that a few times. You're at the mercy of the 3rd party to continue updating and supporting the modules. On top of that, it may not support a particular user case you want to implement. And it's almost worse if it does, because that likely means that it's no longer a simple wrapper around raw terraform resources, but a huge complex beast. In this case, I don't think the author necessarily expects the user to directly user his code. It is a set of examples. The modules themselves are very simple (really just one or two raw resources with vars and outputs)

deleted 6y ago
[deleted]
oblio 6y ago
SAM is a tool created by AWS. It's a set of custom resources plus some CloudFormation macros that expand to CloudFormation templates. It's also a bunch of scripts and utilities that help with the packaging and deployment. At the end of the day you can use it to generate the final CloudFormation template and run that manually, if you want.

deleted 6y ago

[deleted]

_0o6v 6y ago

Comparing SAM and Terraform is like comparing apples and oranges. Comparing Terraform to CloudFormation is more appropriate, and Terraform wins in terms of verbosity there every time. SAM generates CloudFormation templates/stacks, which create your AWS resources. Serverless generates CloudFormation templates/stacks, which create your AWS resources. Related: I wouldn't recommend deploying raw lambda's without a framework. The development workflow really sucks without one. Use SAM or Serverless.

nuker 6y ago
> Comparing Terraform to CloudFormation is more appropriate, and Terraform wins in terms of verbosity there every time. Nope.

simo7 6y ago

Problem with SAM is having to deal with one more tool. But also, maybe even important, it makes things less transparent. I want to be able to refer to the original CloudFormation docs (even when using Terraform) without "translating" every time.

pgroudas 6y ago

I agree that using SAM can be convenient for standalone lambda functions. However, in the context of a larger AWS configuration, where your integration points are already in defined in terraform, the cost of using SAM for these is breaking the invariant that "all our AWS resources are defined in _TOOL_ (in this case, _TOOL_ is terraform). The verbosity is frustrating, but largely ignorable. Having to go back to string references of AWS references defined in different sources of truth is a maintenance nightmare, IMO