Using Lambda Layers for Better Serverless Architecture

Lambda Layers were introduced by AWS in late 2018 as a way to simplify the developer’s life when managing dependencies and shared resources across a multi-Lambda stack. It’s a versatile feature that brings many benefits, which we will discuss in this article.

Using Lambda Layers does increase complexity to monitor and maintain your applications, but there’s no need to fear. Dashbird can seamlessly monitor your functions, as well as its Layers, making it smooth and easy to manage your Serverless stack, regardless of how complex it is.

You can use Dashbird for free, subscribe here (no credit card required).

Shared Microservices

One benefit of using AWS Lambda as a platform for microservices architectures is organizing code for clever reuse and separation of concerns in the service level.

Let’s say we have an application with multiple endpoints, many customer-facing APIs, others serving internal background workloads: data transformation, payment processing, analytical data crunching, etc. Each of these APIs could be served by a single-purpose Lambda:

  • User login credentials authentication
  • Transform an image file to generate thumbnails
  • Process a credit card to charge a recurring bill
  • Etc…

So far so good. We code each of these services, package as a single Lambda, deploy and then instrument how they’ll interact together. Simple and scalable.

Now let’s say we want to send an email, for security purposes, when the same user account faces five consecutive failed authentication attempts. We would also want to email our customers if their subscription renewal fails due to a credit card denial, for example.

This could be deployed as a new service in a dedicated Lambda, just like the others. But since this service would be shared by many others, maybe it would also make sense to deploy it as a layer that could be attached to multiple Lambdas. That’s really a matter of preference, or maybe you would like to save one Lambda invocation charge by AWS. In the scale of several million requests, this could make a difference in our overall bill.

Keep Lambda Package Small

Another benefit of using Layers is to simplify development and keep the main Lambda package small. Say we have a data processing pipeline, with multiple Lambda functions relying on data science packages such as PandasNumpy, etc. These libraries can end up adding dozens of megabytes of data to our Lambda package. Instead of injecting them in every Lambda package, keep them out and deploy as individual layers. Attach the layers to the Lambdas that rely on them and voila: you have a small package size, while still keeping all the heavy dependencies.

Layers also support versioning, which is very handy. Let’s say you need to upgrade Numpy to the latest version, but for only one Lambda, not others. Push a new version of the layer containing the latest library code and update the Lambda pointing it to the latest Layer version. The other Lambdas will keep pulling the old Numpy version from the previous Layer, avoiding backward compatibility issues.

Custom Runtimes

Lambda Layers also support the new custom runtime capability. You can run Layers with code in Julia or Erlang, for example, two languages not yet supported directly by AWS. You can find more information about custom runtimes in this AWS doc.

Read our blog

5 Common Amazon SQS Issues

As with all services on AWS, issues can crop up while using SQS because it’s not always obvious what every service can and cannot do. But fear not, for this article aims to help you solve the most common ones as quickly as possible. Ready to fix your queues? Then let’s dive in!

5 Common Step Function Issues

Here you will find the most common issues when working with Step Functions, especially when starting with the service.

6 Common DynamoDB Issues

It’s expected that developers face many of the same issues when starting their NoSQL journey with DynamoDB. This article might clear things up a bit.

More articles

Made by developers for developers

Dashbird was born out of our own need for an enhanced serverless debugging and monitoring tool, and we take pride in being developers.

What our customers say

Dashbird gives us a simple and easy to use tool to have peace of mind and know that all of our Serverless functions are running correctly. We are instantly aware now if there’s a problem. We love the fact that we have enough information in the Slack notification itself to take appropriate action immediately and know exactly where the issue occurred.

Thanks to Dashbird the time to discover the occurrence of an issue reduced from 2-4 hours to a matter of seconds or minutes. It also means that hundreds of dollars are saved every month.

Great onboarding: it takes just a couple of minutes to connect an AWS account to an organization in Dashbird. The UI is clean and gives a good overview of what is happening with the Lambdas and API Gateways in the account.

I mean, it is just extremely time-saving. It’s so efficient! I don’t think it’s an exaggeration or dramatic to say that Dashbird has been a lifesaver for us.

Dashbird provides an easier interface to monitor and debug problems with our Lambdas. Relevant logs are simple to find and view. Dashbird’s support has been good, and they take product suggestions with grace.

Great UI. Easy to navigate through CloudWatch logs. Simple setup.

Dashbird helped us refine the size of our Lambdas, resulting in significantly reduced costs. We have Dashbird alert us in seconds via email when any of our functions behaves abnormally. Their app immediately makes the cause and severity of errors obvious.