Node v18 Released

[chenrui333]

Even though we are still waiting for node v16 base image, this is the issue tracker for node v18 base image

https://nodejs.org/en/blog/announcements/v18-release-announce/

[jlarmstrongiv]

I’ve been waiting for someone to do this 🤣 thanks

[luizcorreia]

Maybe that way, the Node v18 will be done before past one year.

[mikepage]

Best thing you could do to enjoy Node v18 like-features is move to Netlify. They released Edge functions with Deno deploy: https://www.netlify.com/blog/announcing-serverless-compute-with-edge-functions

Do tell Vercel, they may reconsider using AWS lambda images :)

[chenrui333]

I honestly don't mind receiving flood of email notifications, since we really need to get more ppl to pressure AWS to stay on top of this NodeJS runtime update game.

[davecarlson]

Maybe that way, the Node v18 will be done before past one year.

Honestly, having a 6 month bake (releasing the april LTS release in around October for lambda) would be a good compromise. gives enough time for tests and means we're only "one version behind"

[vith]

Honestly, having a 6 month bake (releasing the april LTS release in around October for lambda) would be a good compromise. gives enough time for tests and means we're only "one version behind"

Isn't that what the 6 months between v18 release on 2022-04-19 and v18 becoming LTS on 2022-10-25 is for?

Amazon can start making v18 images available now if they want to have 6 months of testing before offering v18 as LTS.

[davecarlson]

Honestly, having a 6 month bake (releasing the april LTS release in around October for lambda) would be a good compromise. gives enough time for tests and means we're only "one version behind"

Isn't that what the 6 months between v18 release on 2022-04-19 and v18 becoming LTS on 2022-10-25 is for?

Amazon can start making v18 images available now if they want to have 6 months of testing before offering v18 as LTS.

Yes, that's exactly my point - AWS just also use that same bake time to prepare, then launch the node version as soon as it becomes active LTS

[dl748]

Should be noted as well, that they will be transitioning to Javascript SDK V3 as well for the default SDK.

[adcreare]

Like many others I agree with the sentiments, AWS needs to get better on this. I suggest everyone bug their account managers, technical account managers and log support tickets if you haven’t already.

I went back and dug out the release history of lambda back to node 8. It is not a pretty sight.

The current delay is second only to the delay with the node 10 release, that took until May 13. After Node 10 things got better - Node 12 dropped very promptly, 14 it started to drift back out and with 16 we’re back to at least May.

Interesting to note the other two major cloud providers, ie Google and Azure, did manage to get 16 out in a timely manner.

Node 16: 
    Node LTS: 2021-10-26
    AWS Lambda Release:  ???
    Google Cloud Functions release: 2021-11-17
    Azure  Functions release: 2021-11-22
Node 14: 
    Node LTS: 2020-10-20
    AWS Lambda Release: 2021-02-03
Node 12: 
    Node LTS: 2019-10-22 
    AWS Lambda Release: 2019-11-18
Node 10:
    Node LTS: 2018-10-30
    AWS Lambda Release: 2019-05-13
Node 8:
    Node LTS: 2017-10-31
    AWS Lambda Release: 2018-04-02

[paul-uz]

@adcreare I mean, it's not like Amazon is a multi-billion dollar company.... oh wait

[jtuliani]

Thanks all for the keen interest in seeing Node releases land promptly in Lambda.

Regarding Node releases in general, we're tracking the Active LTS release dates in October, not the 'Current' release dates in April. This is because, as stated at https://nodejs.org/en/about/releases/, "Production applications should only use Active LTS or Maintenance LTS releases".

As @adcreare pointed out above, there have been delays between Active LTS and our corresponding GA releases, not least for Node 16 (see #14 for latest status). While I can't give an ETA for Node 18 yet, we do hear your feedback and this is something we're actively working to improve.

[faradaytrs]

@jtuliani Well you could add it as beta status or something, actually node 12 is also not usable in production because it's not supported anymore, but you still have this runtime supported. I think it's nothing bad about thinking of new releases in advance. "Current" version is stable enough for some simple applications. It's a good idea to release it right when it hits lts status. Having this runtime for lambda doesn't equal using it in production. We might use it in testing instances.

[GrahamCampbell]

Regarding Node releases in general, we're tracking the Active LTS release dates in October, not the 'Current' release dates in April. This is because, as stated at https://nodejs.org/en/about/releases/, "Production applications should only use Active LTS or Maintenance LTS releases".

Then why is your node 16 image that is just released based on node 16.4, which by your version definition, should not be used in production, because it was released multiple months before the first 16.x LTS version!!!

[dl748]

@jtuliani Well you could add it as beta status or something

This is "close" to what I'd like. i'm thinking more like nodejs18.x-experimental that can only to assigned through the API/CLI and not through the console (currently how 16 is working now). Where, if they are are worried about support, have a flag that needs to be sent via API, "agree_experimental": true when sending a runtime of "*-experimental", where the usage agreement is "use at your own risk".... then when GA is ready or close, they make a nodejs18.x

This would allow us to deploy an experimental version and allow us to fix bugs ahead of the GA releases.

If someone wants to use this for production purposes, that's their issue then as they agreed to the terms.

[barneyparker]

-experimental feels problematic in that at some point when the runtime goes GA, AWS need to modify a whole bunch of lambda configs to remove the suffix. Published version configurations would then be modified, which should never happen.

That said, agree_experimental: true is a reasonable thing for non-GA runtimes since that would be required for the API to not fail the call, but would leave things in the correct state at GA - the agreement doesn't need to be stored, its implied by the fact that the API accepted the request.

[dl748]

There shouldn't be a need to remove any configs, however it would be more aggressive on the removal of the runtimes. I would just say, create a new GA runtime without the suffix, and either remove the *-experimental runtime immediately or after a month. They already have policy and protocols for deprecation. The only other thing is, I'd probably disallow the runtime's for @Edge.

The nice thing about it is. Once a GA is announced then they deprecate and immediately release the "next" LTS version. So, if they have node18.x-experimental... after the GA, they release node18.x runtime, where both runtimes exist, then they release node20.x-experimental and remove node18.x-experimental. Experimentals are just treated as another runtime.

[barneyparker]

how do customers deal with the fact that they have an -experimental runtime in a published function, but that runtime has been removed?

its easy to say "make the customer do it" but its an impractical answer that leads to unhappy customers. it would be better to use a fixed name that wont change at GA, but force customers to accept its experimental nature pre GA

To some degree i can see your point that they already have a process for deprecating runtimes, but in this instance it would seem more appropriate to not deprecate, but instead automatically onboard in to the non-experimental version at GA since pre GA the runtime may introduce breaking changes but if you're using the runtime pre GA, you presumably want to keep using it post GA.

This would also address @GrahamCampbell's comment on node 16.4 being available pre LTS. This should have required the experimental: true flag to deploy, but would have naturally transitioned at GA without any actions on the part of the customer

[GrahamCampbell]

but would have naturally transitioned at GA without any actions on the part of the customer

However that's not true, because many major bugs and security issues (such as CVE-2021-22930 and CVE-2021-22931) were fixed since the 16.4 release. 16.4.x is not suitable for production use IMO.

[jtuliani]

@GrahamCampbell Please can you clarify how you checked the Node 16 version and which region you used? When I tried a simple function to console.log(process.version); just now in eu-west-1, I see the Node version reported as v16.14.0. Thanks!

[dl748]

@barneyparker The same way they handle deprecated versions of runtimes now. https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html#runtime-support-policy According to documentation

Phase 1 - Lambda no longer applies security patches or other updates to the runtime. You can no longer create functions that use the runtime, but you can continue to update existing functions.

Phase 2 - you can no longer create or update functions that use the runtime. 

Lambda does not block invocations of functions that use deprecated runtime versions. Function invocations continue indefinitely after the runtime version reaches end of support.

So I would expect, as a completely separate runtime, it would follow these steps but at a "faster" pace, and there would only be one "experimental" per GA release

Edit the main problem is that the experimental runtime may have a "bug" thats not present in the GA version.

[jtuliani]

Thanks all for the thoughts on 'preview' runtimes--please keep the ideas flowing. This is also something we're considering (no concrete plans yet). As well as the details of how preview runtimes would work, we're also keen to understand the 'why'...what would you all see as the main benefit(s)? Would you be willing to try runtimes during the preview phase and share feedback?

[dl748]

@jtuliani The Main reason is for developers to deploy a "test" version of their application. This would allow us to iron out any issues with a new version before (90-99%) a GA is deployed. As it is now, when a GA is released, it can be up to a month sometimes for testing and QA teams to work with before we can utilize this in a production environment. Then all that is left is any issues between a "preview" version and the GA runtimes, which should be low.

[willfarrell]

As the core maintainer of Middy, being able to know what will be included in the runtime when it hits GA will allow myself and other OSS projects to better server the AWS Lambda community. Currently, we need to be over conservative or reactionary with major releases which I feel isn't serving the community as well as it could be. Also, having more lead time mean better planning and less rushing to test and publish a new version once GA is released. Frameworks need to be updated and released before, as @dl748 mentioned, other downstream projects/developers can use them.

I like this idea of having the LTS runtime released via to the API/SDK with a simple changelog in GitHub to know if there are any other changes besides the runtime itself. Then having a switch to GA it once the version transitions to LTS, enabling the console and updating the public docs. I don't think the runtime needs a -experimental suffix, just remove the API flag when no longer needed.

Having access to the latest runtime sooner has additional advantages:

• faster, which lowers costs and can be a competitive edge
• fewer polyfills needed (ie fetch, web stream, etc)
• removal of experimental flags (ie json import)
• simpler and safer build process, js may no longer need to be transpiled

Happy to discuss feedback on preview nodejs runtimes and feature requests I've been collecting over the years. The Middy team is already building a relationship with the AWS Lambda Powertools Typescript team to see how we can better work together to serve the community, would love to do the same with the Lambda nodejs runtime team if there is interest.

cc @lmammino @saragerion @dreamorosi @ijemmy @flochaz

[mbklein]

@jtuliani Could there maybe be a way to differentiate pre-released runtimes from released ones? Something like the CAPABILITY flags you have to include in some CloudFormation calls to confirm that you know you're doing what you think you're doing? For example, if I tried to execute CreateFunction with a runtime of nodejs18.x but without some kind of IncludePrereleaseRuntimes parameter, I'd get an InvalidParameterValueException (or something). Including that flag lets me select unsupported runtimes, with the full knowledge that what I'm doing isn't (yet) supported. I think it'd provide a good balance of trusting developers/users with the flexibility to do what they want while still making sure you're not fielding support requests for things in pre-release state.

That said, I understand that changing the public API is way harder than some of the other solutions presented. One way around that might be to change the actual name of the runtime to, say, nodejs18.x-pre until it's supported. Anything that makes selecting it a deliberate act that forces acknowledgment of its prerelease status.

[paulgalow]

I like the idea of implementing Node 18 current and LTS with the same runtime name of nodejs18.x. I see a chance this might make it easier for adjacent software projects to keep their runtime support up to date and implement support by the time Node 18 LTS is released.

For example: Frameworks like Serverless Framework, plugins (like serverless-esbuild) or IDE extensions like Serverless IDE. All of them have/had to add support for the latest runtime and all of them have been blocked/waiting until May 9 to get started, making an already late runtime release take even longer because of the time required for dependencies to follow suit.

If AWS released nodejs18.x before Node 18 LTS, all of those projects could start working on support for it months earlier. And as mentioned before, we all could run and test Node 18 current much earlier to iron out issues. So by the time LTS hits, we could have a much more mature state of support throughout the ecosystem.

[pbadenski]

FYI As AWS is painfully slow at releasing new versions of node images we build our own lambda layers. We've been running our services on the latest node using layers for number of years now. At the moment we are not even able to do that as Node 18 requires glibc >= 2.28 currently unsupported by Amazon Linux (AL1 and AL2). What I think it means - is that we will not have Node 18 on AWS Lambda until it's operating on Amazon Linux 2022 (also see: https://repost.aws/questions/QUrXOioL46RcCnFGyELJWKLw/glibc-2-27-on-amazon-linux-2).

[willfarrell]

NodeJS just moved up the EoL for v16 to 2023-09-11! The race is now on for all vendors to release v18 ASAP to ensure customers have sufficient time to upgrade. Hopefully this will force a new release schedule.

https://nodejs.org/en/blog/announcements/nodejs16-eol

[lmammino]

I totally agree with @willfarrell that this is becoming much more of a priority right now. Hopefully AWS can prioritise this work

[pbadenski]

FYI we figured out how to build a custom node 18.X layer on Amazon Linux 2 with the help of AWS support (requires patching node binary with different glibc): https://gist.github.com/pbadenski/2011f2763ca572c2475a37433cb59549

[jlarmstrongiv]

NodeJS just moved up the EoL for v16 to 2023-09-11! The race is now on for all vendors to release v18 ASAP to ensure customers have sufficient time to upgrade. Hopefully this will force a new release schedule.

Probably a good time to migrate from the AWS Linux 2 base image to the AWS Linux 2022 base image too

[paul-uz]

@pbadenski how are you finding cold starts when using the node18 layer?

I'd be interested to use it, as long as response times didn't suffer

[pbadenski]

Analysis of 5 days of data shows cold start durations: [min: 1000 ms, avg: 1500 ms, max: 3500 ms]. These can be quite significant, however - we're not that sensitive to cold starts and only 0.5% (1 in 200) of our requests are cold starts.

Hope this helps.

P. S. Thank you for your question - cold starts never been an issue for us, so I've never checked it. I've learnt something! :)

[paul-uz]

Analysis of 5 days of data shows cold start durations: [min: 1000 ms, avg: 1500 ms, max: 3500 ms]. These can be quite significant, however - we're not that sensitive to cold starts and only 0.5% (1 in 200) of our requests are cold starts.

Hope this helps.

P. S. Thank you for your question - cold starts never been an issue for us, so I've never checked it. I've learnt something! :)

Could you tell me how to best gather metrics on cold (and hot) start times?

PS thank you for checking, very helpful

[hutchy2570]

Analysis of 5 days of data shows cold start durations: [min: 1000 ms, avg: 1500 ms, max: 3500 ms]. These can be quite significant, however - we're not that sensitive to cold starts and only 0.5% (1 in 200) of our requests are cold starts.

Hope this helps.

P. S. Thank you for your question - cold starts never been an issue for us, so I've never checked it. I've learnt something! :)

What is your memory configuration for these metrics?

[pbadenski]

@paul-uz https://georgemao.medium.com/analyze-your-aws-lambda-logs-with-cloudwatch-logs-insights-170a5b58225a

@hutchy2570 2048MB

[fromtheexchange]

@jtuliani following up from https://github.com/aws/aws-lambda-base-images/issues/14#issuecomment-1120864028

Will you also be updating https://github.com/aws/aws-lambda-nodejs-runtime-interface-client/issues/44#issuecomment-1032928940 ? I open-sourced prebuilt packages for amazonlinux:2022, but I need parity between your default aws-lambda-ric and the docker aws-lambda-ric, especially for ESM support.

@fromtheexchange That's a great question regarding the alignment of RICs. This is something we currently plan to address in Node 18.

In addition, the official amazon/aws-lambda-nodejs image on https://hub.docker.com/r/amazon/aws-lambda-nodejs needs to be updated to include the linux/arm64 architecture.

Finally, it may be worth looking into the base image migration to amazonlinux:2022 from amazonlinux:2

Thank you for improving NodeJS support in AWS Lambda 🚀

[jtuliani]

@fromtheexchange Thank you for the suggestions. We are aware of the AL2 -> AL2022 transition and are working on plans for how to roll this out in Lambda, although at this stage we're not in a position to give a schedule. It's a little complicated because the minimum Linux kernel version is different between AL2 and AL2022.

[joebowbeer]

A general question about AWS Node.js support: What does it mean for AWS to support a Node release AFTER the EOL of that release?

Using Node 16 as an example:

From AWS Lambda adds Node.js 16 -

Node.js 16 is the latest long-term support (LTS) release of Node.js and will be supported for security and bug fixes until April 2024.

Given that Node 16 reaches EOL in September, 2023, how is AWS planning to make security and bug fixes after that date?

[rktyt]

@joebowbeer It seems that AWS just hasn't made any announcements regarding the shortened support period for Node.js.

AWS announcement is May 12, 2022. (see What's New Feed (with filtered about Lambda)) Node.js Announcement is June 8, 2022 (https://nodejs.org/ru/blog/announcements/nodejs16-eol/)

---

AWS Lambda runtime deprecation policy shows that it can be called after EOL, but I assume it will just be left unpatched.

[jtuliani]

In general, the schedule for Lambda runtime deprecations tracks the language version they support (there have been exceptions e.g. Python 2.7). Customers should not plan on Lambda runtime support extending beyond the LTS period of the corresponding language version. This applies to the shortened EOL for Node 16.

We recognize that the shortened LTS period for Node 16 will increase demand for early support for Node 18, and are factoring this in to our Node 18 planning.

[willfarrell]

Is there a status update on when this will be ready or in preview? The next version on Middy, v4, with support for NodeJS 18, AWS SDK v3, and many more requested features is nearly ready in anticipation of an earlier release.

[jtuliani]

Work on Node 18 support for AWS Lambda is in progress. There are various dependencies which mean we're not able to share an ETA at this time.

[GeoffreyEmerson]

Node v19 released. https://nodejs.org/en/blog/release/v19.0.0/

That means v18 is feature stable, right?

[IvanMoucha]

Node v19 released. https://nodejs.org/en/blog/release/v19.0.0/

That means v18 is feature stable, right?

The Active LTS is starting 2022-10-25. After this date, it will be feature stable.

In the language of the Node.js team: "New features, bug fixes, and updates that have been audited by the LTS team and have been determined to be appropriate and stable for the release line."

[rohanrajpal]

Nodejs v18 is LTS since yesterday, so yep!

Node v19 released. https://nodejs.org/en/blog/release/v19.0.0/

That means v18 is feature stable, right?

[o-alexandrov]

Oh wow, seems like AWS is rolling out Node.js 18 for AWS Lambda. @jtuliani Could you please clarify?

[jtuliani]

Well spotted, that was quick :)

Yes, we have shipped a Node 18 base container image, which you can use to create and deploy Node 18 functions if using container images as your function deployment format. The remainder of our Node 18 support (managed runtime, SDK, SAM CLI, CDK, AWS CLI, docs etc) will take a few more weeks, and we will make the formal announcement when all those are in place.

Note that the Node 18 image includes the AWS SDKv3 (replacing v2 in Node 16). If you're giving it a try, please bear this in mind.

[paul-uz]

Well spotted, that was quick :)

Yes, we have shipped a Node 18 base container image, which you can use to create and deploy Node 18 functions if using container images as your function deployment format. The remainder of our Node 18 support (managed runtime, SDK, SAM CLI, CDK, AWS CLI, docs etc) will take a few more weeks, and we will make the formal announcement when all those are in place.

Note that the Node 18 image includes the AWS SDKv3 (replacing v2 in Node 16). If you're giving it a try, please bear this in mind.

Sorry, does this mean Cloudformation can use Node 18 now?

[o-alexandrov]

@paul-uz Node.js 18 is currently available only for AWS Lambda functions that use custom container images (Docker). That’s the only aspect where we should expect to see CloudFormation changes.

… (the rest) will take a few more weeks

[paul-uz]

@paul-uz Node.js 18 is currently available only for AWS Lambda functions that use custom container images (Docker).

… (the rest) will take a few more weeks

Ah lovely thank you. I wasn't sure where Cloudformation came into it you see. Thanks for clarifying.