Lambda Layers
Lambda layers are much like node packages as they allow us to share code among lambda functions. Layers were introduced to avoid duplicate code across many lambdas so are great for separation. Layers can be developed using the Serverless Framework or AWS SAM CLI.
Overview
You can currently add up to 5 layers per function. You can also have layers which are interdependent which can add to the complexity of managing them; also order is important when using layers that depend upon each other as you will run into race conditions.
Layers are immutable. This means that once the layer has been updated and deployed, AWS will return a new version number. The issue with this is we are not in control of the semantic versioning. This also requires you to manually updated dependant lambdas. Some plus points on this is we can use CloudFormation to automate the update process. This is explicitly done by using the ARN of the layer. CloudFormation will automatically pick up the latest ARN whilst it is being deployed. The issue here is if we are promoting breaking changes, that will be promoted to all lambdas which consume the layer and you will have to extensively test them before deployment.
Pros
- Extends functional code inside your lambda as it is removed from the artifact
- Reduces initialization
- Has a size limit of 250mb. Whilst some may think this is an issue, if your layer contains that much code it is time to refactor or find a new approach
Cons
- Not able to control versioning
- Easier to have breaking changes across lambdas which are decoupled
- When a layer is updated you are unable to redeploy lambdas referencing it until they are fixed