Quite an exciting title, isn't it? I was hyped when I heard AWS was adding support for custom runtimes and layers for AWS Lambda. This means you can now build your own custom artifacts, enabling you to share and manage common code between functions.
I won't say I fainted when I heard the announcement. But, I did. Don't tell anybody.
What'll we be doing?
This article will show you how to hook up a custom Node.js 11 runtime to AWS Lambda. We'll create a simple Serverless project with a sample function, and add a layer that will enable us to run the Node.js 11 runtime.
How it works
To use a custom runtime, you have to specify that you're providing one when deploying your function. When the function is invoked, AWS Lambda will bootstrap your runtime code and communicate with it over Runtime API to execute the function code.
That's enough about custom runtimes. What are AWS Lambda Layers? They're a new type of artifact that can contain arbitrary code and data. It can be referenced by multiple functions at the same time. That's so awesome! Your functions usually share common dependencies like SDKs, prebuilt modules, libraries, and frameworks. Here's the kicker, now you can share runtimes as well!
By using AWS Lambda Layers, you can manage components that are used across multiple functions. Allowing better code reuse and more DRY code.
Using them is simple, you put the common code in a zip and upload it to AWS Lambda as a layer. You can also upload it as a CloudFormation template, then configure your functions to use it. The layer content will be available to your function code. But that's a topic for another tutorial.
Let's jump into using a custom Node.js v11 runtime!
Configuring the project
I’ll assume you already have a basic understanding of the Serverless Framework. I would also hope you have an AWS account set up. If you don’t, please check this out.
Note: Update the Serverless Framework to v1.34.0 or greater for layers support
1. Creating a service
As always we need a fresh service to hold all our code.
$ sls create -t aws-nodejs -p node11 && cd node11
After running this command you'll find yourself in the node11 directory alongside a nice boilerplate to start building your functions. Next step is to open up the serverless.yml and add our layer.
2. Adding the Node11 layer to serverless.yml
There are a lot of prebuilt layers to choose from. Luckily, the serverless community is awesome! We'll go ahead and grab the custom Node.js runtimes.
You can pick either one, but I'll go with v11. Open up the serverless.yml now, delete all the contents and paste this in.
service: node11
provider:
name: aws
runtime: provided # set to provided
functions:
hello:
handler: handler.hello
events:
- http:
path: /
method: get
layers: # add layer
- arn:aws:lambda:us-east-1:553035198032:layer:nodejs11:3
It's enough to add the layer ARN and the function will pick up the runtime. Don't forget to add the runtime: provided field as well.
3. Adding code to handler.js
Moving on from here you'll feel right at home. You can finally write bleeding edge Node.js code on AWS Lambda. We've been waiting for this for a long time.
Open up the handler.js and paste in the snippet below.
exports.hello = async (event, context) => {
console.log(`Hi from Node.js ${process.version} on Lambda!`)
return {
statusCode: 200,
body: JSON.stringify({ message: `Hi from Node.js ${process.version} on Lambda!` })
}
}
Pretty simple snippet of code, but it proves a point. Making sure we're running Node.js v11.4.0.
Deploying the project
The Serverless framework makes deployments quick and painless. All you need to do is to run one command.
$ sls deploy
It'll create a CloudFormation template, provision resources and deploy the code. All in one command.
The deployment went well. Hit the URL with a curl to make sure it works.
$ curl https://<id>.execute-api.us-east-1.amazonaws.com/dev/
You should see {"message":"Hi from Node.js v11.4.0 on Lambda!"} get echoed back. It works great!
Wrapping up
With the latest improvements to AWS Lambda, new supported languages, new runtimes, and layers, it's becoming so much more than just a supporting service to the main VM and container services. Serverless architecture is becoming a force to be reckoned with. I can't wait to see where it will take us from here!
Here's the repo if you got stuck following the tutorial, give it a star if you want more people to see it on GitHub. If you want to read some of my previous serverless musings head over to my profile or join my serverless newsletter!
If you need a serverless analytics framework, check out Cube.js. It's open source and on GitHub. Or, if you want to read more about serverless architectures, feel free to read more serverless related articles on the Statsbot blog.
- Building a Serverless Stripe Analytics Dashboard
- A crash course on serverless-side rendering with React.js, Next.js and AWS Lambda
- A crash course on Serverless with AWS - Building APIs with Lambda and Aurora Serverless
Hope you guys and girls enjoyed reading it as much as I enjoyed writing it. If you liked it, don't hesitate to share. Don't forget to give the Statsbot blog some love.
Disclaimer: Zeet is sponsoring this blogpost for the next month. I tried it out the other day. It's like serverless but for running entire back ends. You can host and scale apps automagically. Pretty neat.
Top comments (3)
Great article. I find it strange that the runtime to be used is specified in the .yml file by 'layers: arn:aws:lambda:us-east-1:553035198032:layer:nodejs11:3' i.e specifying the layers property. Its as if they are the same concept/thing?
Thanks! Glad you liked it. Take a look at how AWS explains it. Runtimes are essentially packages of code that you provide to your functions. You use the capabilities of Layers to provide that code. Check out how you can add your own runtime. It's an awesome concept, and I can only see this growing in the future!
Amazing post 😊 thx