Node v20 Released

[zackheil]

Today Nodejs released v20: https://nodejs.org/en/blog/announcements/v20-release-announce

Since there were similar issues to track v16 and v18 adoption for Lambda, I wanted to open this issue to inquire when the team thinks this release will be available.

[jtuliani]

Thank you for creating this issue @zackheil. We don't yet have a schedule to share for Node 20 support in AWS Lambda. We will update this issue when we do.

Note that we only consider Node releases as suitable for a General Availability release in Lambda once they reach the 'Active LTS' stage of the Node release cycle (see https://nodejs.dev/en/about/releases/). This is to avoid breaking changes impacting customer functions when Lambda applies automatic runtime updates.

[michael-k]

avoid breaking changes impacting customer functions when Lambda applies automatic runtime updates

Don't customers who want that stability have the option to use runtime management controls?

[jtuliani]

@michael-k Lambda runtime patching aims to be fully backward compatible. Our customers expect this stability so they can focus on their code while we take care of patching. In the extremely rare cases where a function is impacted by a runtime patch, runtime management controls provide a way for customers to mitigate that impact. They do not lower our backward compatibility bar.

[michael-k]

For GA runtimes, sure. But a lot of customers wouldn't mind a Node.js 20 pre LTS runtime that doesn't provide that reliability out of the box.

But for now the Lambda's team is probably better spent on releasing new runtimes for stable versions. The Node.js 18 runtime came out pretty quickly after the LTS phase began, but other runtimes (incl. Node.js 16) took ages.

[jcollum-nutrien]

been 2 months, any update? is there a PR / branch we can track?

[GrahamCampbell]

been 2 months, any update? is there a PR / branch we can track?

No, AWS Lambda is mostly closed source.

[shellscape]

Folks, it takes them a year+ to implement support for a new Node version. It took this crack team 13 months to add v16 to the runtimes (see #14). they managed to pull off Node v18 (#47, https://aws.amazon.com/about-aws/whats-new/2022/11/aws-lambda-support-node-js-18) in 7 months - and introduced a massive cold start bug which they still haven't fixed (#47 (comment) acknowledged by @jtuliani back in February).

All folks need to know is: This team is terribly slow compared to the rest of the industry, is opaque in its process and prioritization, and is perfectly content to let thoroughly embarrassing issues drag for months on end. No one should expect anything different at this point.

[o-alexandrov]

@shellscape I don’t work for AWS, but statement about cold starts is factually inaccurate. Whereas the timeline was already given for node.js 20, as Active LTS was mentioned with a link that shows end of October 2023

[shellscape]

@o-alexandrov true, there was no announcement of a fix, @jtuliani didn't follow up on the original issue (#47) where it was acknowledged. without having you point that out I would have never known it was addressed since I'm not in the habit of cascading into every referenced issue, and I'm sure that it'll continue to cause confusion.

Whereas the timeline was already given for node.js 20

Your turn for a factually inaccurate statement 😄

Note that we only consider Node releases as suitable for a General Availability release in Lambda once they reach the 'Active LTS' stage of the Node release cycle

There's not a timeline. That's saying that they'll begin to consider the new version once it reaches a particular state. Hence, my original statement about folks' expectations remains - don't expect speed here. While the rest of the Node ecosystem starts using "current" builds, AWS will languish behind.

[shellscape]

Node v16 just hit EOL today. https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html

@jtuliani y'all are falling even further behind the ecosystem. It's reached comical heights.

[jtuliani]

Today, we have published a preview AWS Lambda base container image for Node.js 20. You can use this image to build and deploy Node.js 20 Lambda functions if using container images as your function deployment format.

This image is tagged ‘preview’ and should not be used for production workloads. We invite you to provide your feedback on this preview image below. We are aiming to provide GA support for Node.js 20 in Lambda, as both a base container image and a managed runtime, by the end of 2023.

The Node.js 20 image is based on the provided.al2023 preview image. Note the use of microdnf as the package manager when updating your Dockerfiles to use this preview.

In this release we are no longer including extra root CA certs, such as RDS certificates, by default. This is to improve cold start times. We recommend that you bundle the certificates you need with your deployment package. Alternatively, to revert to the previous behavior, set the NODE_EXTRA_CA_CERTS environment variable to /var/runtime/ca-cert.pem, which contains the extra root CA certs.

[estrudels]

We are aiming to provide GA support for Node.js 20 in Lambda, as both a base container image and a managed runtime, by the end of 2023.

@jtuliani This is fantastic news thank you for sharing!

[o-alexandrov]

aws-sdk just released node.js 20 support for Lambda. I’ll be waiting for aws-cdk support, but if anyone kindly shares their experience with aws-sdk, it’d be great

[willfarrell]

aws-cdk support: aws/aws-cdk#27897

[juancarlosjr97]

Awesome! New Node 20 base image published on AWS without preview 🥳

[jtuliani]

We're happy to announce Node.js 20 is now supported in Lambda as both a managed runtime and base container image. Please feel free to share any feedback.

https://aws.amazon.com/about-aws/whats-new/2023/11/aws-lambda-support-node-js-20/

https://aws.amazon.com/blogs/compute/node-js-20-x-runtime-now-available-in-aws-lambda/

[o-alexandrov]

@jtuliani I was very hyped about Node.js 20 after your comment above on what AWS did to decrease cold starts.
Unfortunately, the cold starts are a lot worse than Node.js 18/16/14 for non-Graviton (non-ARM) and pretty much the same as Node.js 16 for Graviton.

• out of topic opinion: it's extremely disheartening to see AWS lagging behind the competition (performance-wise for JS developers); for example, comparing to CloudFlare Workers

[GrahamCampbell]

The blog post mentions lazy loading. I wonder if the fact that a bunch of work has moved out of the INIT phase is going to cause lower performance for many workloads.

[jtuliani]

Thanks all for the feedback.

The impact of lazy loading will depend on your workload and on your configured memory size. You should make performance comparisons that are specific for your workload and configuration.

When we launch a new runtime, usage is very low, which affects cache hit rates and cold start times. This typically improves in the weeks after launch, as usage ramps up.

The cold start optimization relating to CA certificate loading is described in more detail in our blog post.