The Lambda Trilogy

You can clone this pattern from cdkpatterns.com today through one command:

npx cdkp init the-lambda-trilogy

Deconstructing The Lambda Trilogy

What is it?

The three states of AWS Lambda are something that has been discussed by many serverless heroes since their invention. This is probably the most controversial subject in all of serverless so I am not going to tell you which of the three is the best because like everything you need to adapt the right implementation to fit your context!

Some examples from Paul Swail, Yan Cui, Jeremy Daly and others:

• Jeremy Daly & Paul Swail Serverless Chats #41
• Jeremy Daly Off By None
• Yan Cui Presentation (slide 41 on)
• Yan Cui re:Invent 2019
• Yan Cui Hackernoon - monolithic or single purpose functions?
• Yan Cui monoliths vs cold starts
• J D Hollis medium.com
• Ryanne Dolan medium.com

The three states are:

Description

This is the purest of all the serverless patterns. Each lambda does one unique function and the code is in its own file.

Pros

• Maximum code reusability
• Forces you to write more testable code
• Introduces lowest cognitive burden for developers making changes to that individual function
• Easier to optimize your lambda execution times and by extension costs

Cons

• Only works for fully event driven architectures
• Seeing the bigger picture, congnitive burden increases as system wide changes are talked about
• Maintenance as it grows (how do you make sure 7000 lambdas have no code vulnerabilities?)

Description

This is a compromise option where we can still have individual lambdas but we group the actual code together in one (or more) files. You would decide what goes into a file based on low coupling, high cohesion arguments like in traditional development.

Pros

• Related logic is grouped together making your code easier to see the bigger picture
• Code can easily be shared between lambda functions without needing things like layers
• Security footprint reduced as updating one file can update many lambda functions

Cons

• How big is too big? Every extra byte of code added slows your lambda cold start times.
• Increased blast radius of changes. Now one line of code being changed could bring down a section of your infrastructure instead of one lambda.

Description

This is using the lambda runtime container like a docker container. You use a web framework like Flask or Express and put them inside the lambda, then have your api gateway pass all requests through to the lambda and have that framework process the request.

Pros

• You can have an identical local development experience to deployed since you are using no AWS specific features
• The code could be moved to Fargate later if it got too big for lambda with minimal changes (or another cloud)
• Developers already know these frameworks

Cons

• Is this really what Lambda excels at? The larger project sizes will increase cold start times and there will be restrictions on incoming/outgoing payload sizes
• Higher exposure to cold starts as the lambda will spend longer processing events
• Lower levels of code reuse as probably still building the traditional ball of mud
• Adapters required to make existing frameworks work with lambda. These are in various states of maturity and are another potential vulnerability in your app.

CDKPatterns Implementation

You can clone this pattern from cdkpatterns.com today through one command:

npx cdkp init the-lambda-trilogy

Both TypeScript and Python versions of all 3 lambda states are available.

The lambda-lith in Python uses Flask and in TypeScript uses Express.js