Preferred deployment framework

[heitorlessa]

Summary

Preferred deployment framework to use throughout the project lifecycle. We can update this with examples for each tool later to get the ball rolling quickly.

Why

We need to optimize for a single deployment framework that we will feature in the session and align to our project setup/practices.

Proposal

We've agreed to continue with CDK for the scope we have at hand: API Gateway -> Lambda -> DynamoDB -> Lambda -> EventBridge.

For completion, these are the main considerations we've looked at but not exclusively:

SAM

Declarative approach using YAML as the configuration language.

• Pros
  • No client side effects thus less cognitive overload (testing, security, etc.)
  • Native integration with Docker for builds
  • Server-side state definition
• Cons
  • Not all team members are comfortable
  • Requires custom build and IDE settings for non-trivial Python apps
  • Verbose boilerplate for non-native integrations (e.g., Fargate, VPC, IAM, etc.)

CDK

• Pros
  • Batteries included for Serverless and non-Serverless (should we need)
  • All team members are comfortable
  • Template for customers post-session incorporating practices use CDK
• Cons
  • Easy to over-engineer and create side effects + cognitive overload
  • Need for testing custom constructs logic
  • Operational overhead to handle CVEs, dependencies, etc.

Potential challenges

N/A

Out of scope

N/A

[having-fun-serverless]

@heitorlessa , I'm missing the fact that SAM also provide full Serverless suite, with its CLI, for example:

• Local testing and debugging
• Monitoring

It's a one stop opinionated shop.

[ran-isenberg]

here's my list:
@heitorlessa @aws-hebrew-book

CDK
Pros:

• Native support for docker (can be seen as a pro or a con, as docker requires license for enterprise usage, and you can build lambda funcs without docker
• Write code, define resources with code that you can debug, read its' documentation, import and and share instead of YAML
• Supports multiple programming languages (I'll refer to Python here)
• Write constructs which are a set of resources with relations between them. Can share and import construct between teams
• Can manage versions of constructs or CDK stack by using native Python dependancy management
• Easy to update constructs by running poetry update
• Adds abdtraction over CF
• Strong community (CDK Day conference )and many shareable constructs and code
• Complies down to CF template
• Has built in testing framework (can be see also as a con but I think it's important to verify your CF template is correct no matter the framework
• Has integration with CDK nag - SAM/CF have a similar tool

Cons

• Requires many dependancies and managing their versions, not only in Python but also Node
• Documentation can be lacking sometimes
• Many services or sub services lack L2 or even L1 (higher abstraction) construct and you need to resort to writing pure CF
• can over abstract and get hard to manage/read code
• No clear best practices, too many options to do things
• Can get resiliency or security wrong with bad defaults. Developer are required to think about these matters and make sure everything is set correctly
• When using default grant_X permissions, you provide in most of the times too many permissions that you dont require.
• No clear guidelines on building constructs
• Can raise exceptions
• When doing refactors, naive programmers can change logical ids of stateful resources and get them deleted (with their data) and rebuilt, resulting in data loss. There are ways to prevent it but not everybody is well aware of it. This is due to CF but you need to understand that when working with CDK