Lambda Layers and Custom Runtimes
Last week at re:Invent AWS launched Lambda Layers and Custom Runtimes for Lambda which is pretty amazing technology. This allows you to do a huge amount more with Lambda and removes a number of the issues that people have for Lambda.
As a quick overview, Lambda Layers allows you to create an artifact that can be referenced by multiple Lambda functions at the same time — similar to a shared library in code. This is useful in that many companies using Lambda end up with a shared codebase across a number of functions and this tends to end up in a “shared” folder in a repo somewhere (depending on which runtime is being used). This avoids that shared code problem, and allows you to move that into a layer which is then separate from the functions themselves.
It does make testing a little different because you test the layer separately. However, AWS have thought of this and by using SAM local it will download and cache the layer on your local machine, and you can test locally. That means you will have to create and test your layer separately and push it to the cloud first, but that’s actually no bad thing.
Best Practices for Layers
They haven’t been out for long, but the best practices for layers are relatively straight forward as I see it. A layer is only really used for code that will be shared across multiple functions. There is no need for a layer otherwise. Of course, something like NumPy and SciPy which AWS has provided are good examples but you can always put these into a Lambda function yourself anyway.
So, the best practice?
They should be small
They should do one thing *
They should limit your exposure to technical debt
*”thing” is a relative term here and will be a collection of functionality e.g. “NumPy is a fundamental package for working with scientific computing with python”
A Lambda Layer will collect shared functionality around a specific domain for use across an organisation or wider.
The limitations around 5 layers per function and the total unzipped package size being no more than 250MB will mean that you can’t simply build all your complexity in layers, and that means minor limitations, but there is significant value within those constraints.
I cannot wait to see what people do.
There’s even a layer that allows you to run PHP (well played Stackery)!
Custom Runtimes are also a really exciting move. Put simply, this allows you to install and use a language not specified in the Lambda runtimes list, by creating a bootstrap file that follows certain criteria. There are even instructions on how to build a custom runtime for bash.
This is really exciting. It removes one of the hurdles that is often thrown at Lambda of not being able to use a specific language or a specific version of a runtime. Well now you can.
There is a downside though.
You are scraping off a layer of the abstraction that Lambda provides to get that customisation. It’s the kind of thing you should only do if you need it. You will have to manage that runtime from that point forwards, so bear that in mind.
If you need the customisation though, and you are prepared to take on the management responsibility, this will be a huge boost.
And as Kesley Hightower states, there shouldn’t be a need to put container support into Lambda as this solves the problem for the developer…
This will not be a big part of Lambda for most people, but it will always be available for that moment when a developer needs a customisation that just isn’t quite doable in the main Lambda runtimes.
One very big note of caution is to say that you should only be reaching for a custom runtime in a “last resort” scenario. Developers should not be designing the majority of systems around custom runtimes (although of course they can). The value of Lambda is it’s simplicity in code base and removing the management of system resources and servers. So you should be primarily using provided runtimes (of which there are many) and should use custom runtimes in highly specific scenarios where a provided runtime cannot be used.
How Layers and Custom Runtimes changes Lambda
These are very powerful technologies. In reality, they don’t change a lot about how a company will use Lambda as I see it. However, they do allow companies to do much more with Lambda by giving more options for how to use Lambda.
Layers allows more code sharing across Lambda
Custom Runtimes allows more flexibility in language and version for Lambda
The breadth of opportunities to use Lambda in an event driven scenario make these technologies of even greater importance now for any business doing compute on the cloud. If you haven’t started looking at serverless yet, now is probably the right time to start.