## AWS Lambda layers --- ## How did I come across this and why? --- ## Distributed logging in serverless * To ensure a standard logging format for across microservices. * To make it easier to manage logging as a seperate layer. * A way to be able to decouple dependencies so that it can be scaled to multiple services without repeating logic. --- ## What is it? Lambda layers is just a way provide a convenient way to package libraries and other dependencies that you can use with your Lambda functions. --- ## What can it do? * It can be used to reduce size of uploaded deployment and make it faster to deploy your code. * It can contain libraries depedencies, custom runtime or configuration files. * Promote code sharing and separation of responsibilities. * Can be shared with other AWS account and made public. Ex. [Existing public layers](https://github.com/mthenw/awesome-layers) --- ## Play I've created a simple nodejs pino-lambda layer that can be attached to function to use the the logging logic and configuration that maintained and versioned separately. [yoonkean/aws-lambda-logging-layer](https://github.com/yoonkean/aws-lambda-logging-layer) --- ## Best practices * Should be small * Should do one thing only * Not recommended for dependencies that is constantly updated or changing. * Best use as a deploy time optimizer if required. --- ## How does it compare to a package manager like NPM? If your layer logic is simple, small and something that doesn't change often. Better to just use package manager because of it's limitations. --- ## Limitations * Limited to 5 layers per function and it's size cannot exceed 250MB. * No semantic versioning. * Sharing the layer is not straightforward. * Need to package and publish. * Need to add resource policy. * User need to know latest version or if it's a breaking change. * Need to manually update Lambda config to reference latest layer. * Can only be used by functions deployed as .zip file.