AWS Lambda[0] and GCP Functions[1] both say they support only up to Node 16 today. Hopefully they'll get new versions shipped with enough lead time for customers to upgrade ahead of the deprecation. (There are things like Cloud Run to bring your own container that could be used sooner)
AWS have already openly admitted that they were slow bringing Node 16 support and plan to be quicker next time round.
> We recognize that customers have been waiting for some time for this runtime release. We hear your feedback and plan to release the next Node.js runtime version in a timelier manner.
I don’t know the AWS ecosystem but in the meantime on GCP at least just use Cloud Run rather than Cloud Functions and keep whatever run time you want and pick up a bunch of other benefits in the process.
Their latest version of Cloud Functions is actually using Cloud Run under the hood already.
Cloud Run introduces a heap of other considerations at the enterprise level - container building and repository management which may not be managed by your team etc.
Cloud Functions/Lambda are very nice in a company where you don't necessarily have access to making your own AMI, or container image etc.
At least that's what we used them for at my old job. Still had to deal with some level of corporate tech indirection (E.G. We couldn't make the API gateway however we wanted, our account had no access to route53 etc.), but much less than with containers. It was just a quicker way to get code running.
I should have mentioned this in the original post but the missing piece of the puzzle to help close that gap is Buildpacks https://buildpacks.io/ which gets you out of the path of having to think about creating containers and again AFAIK is what Cloud Functions is using under the hood.
I agree for recent history at least. With that said, recent releases also haven't brought life changing changes either, so the incentive to upgrade remain low even if it's mostly painless.
M1 added a lot of headaches to that... some older libs don't support newer Nodes running in native Apple Silicon mode :(
Upgrading from 16 to 18 on Windows or Linux took me like 2 minutes of resolving some conflicts. That same repo took several days of investigation on M1, and eventually I gave up...
NodeJS becomes LTS in October. That leaves people 11 months to switch. It is out right now albeit not LTS, so you can prep the switch and switch as soon as it becomes LTS.
If they’d move to LTS a month earlier, not a whole lot of people would gain something from it.
It seems like the most reasonable choice. Incidentally, I have an open-source tool called Node Version Audit [0] which checks a given node version against known CVEs and end-of-life dates. It looks like the official change hasn’t been made yet [1].
Why didn't they foresee this before releasing Node.js 16? OpenSSL 1.1.1's lifecycle[0] was known well in advance of the Node.js 16 release. Why did they release it with an EOL date they could have known was impossible, and then later change the EOL date? This seems like a release engineering failure. Communication now is great but they had an opportunity to get this right from the beginning. As a result, we can all now be certain that Node.js's LTS support dates don't mean anything; they don't have the engineering discipline to make support promises they can keep. On multiple occasions now they've shortened their published LTS support periods after the fact.
I’d cut the Node team some slack, they’ve been doing phenomenally scheduling EOL and LTS support over the years. They’re notifying everyone 1.5 years in advance. They have some of the best backwards compatibility I’ve witnessed in software which means updating will be easy.
I think that this is a quite harsh. The EOL for Node 16 is more than a year away, there's a good reason for the EOL change, and Node 18 will be LTS almost a year by then.
Chill. To err is human. They are communicating this welll in advance so everyone has about a full year to update to Node 18 LTS. I’d say that is a very reasonable timeframe.
The dates were known in advance - however, the Node.js team expected OpenSSL 3 to be out before the release of Node 16, but it didn't happen - so they had to release with OpenSSL 1.1.1. I think that there was some minor hope of maybe upgrading, but obviously it was too backwards-compatibility breaking to land without a new major.
> The OpenSSL 3.0 release schedule is documented on the OpenSSL 3.0 Release Schedule wiki page. We expect the final release to be in early Q4 2020.
Node 16 Release date:
> 2021-04-20
They gave themselves 3-6 months buffer from 3.0 release to Node 16 release, and decided to move forward when OpenSSL was 4-6 months behind schedule, with no idea when 3.0 would release
OpenSSL was then released in SEPTEMBER of 2021, nearly a year late, and 4 months after Node 16's LTS start date.... As of April, the Node team could not know if OpenSSL was going to be released tomorrow, next month, or next year
I think they made the right choice to keep moving forward instead of halting work waiting on OpenSSL to get back on schedule... by April 2021, when SSL 3.0 was already ~5-6 months behind, I would have expected them to extend support for 1.1.1 for another few months... they didn't but that's mostly a moot point -- OpenSSL has committed to security fixes through the Node 16 end-of-life.. but the Node team isn't comfortable with that, so they made a change
It seems I didn't make my suggestion clear, since you seem to be arguing against a point I didn't make. I'm saying they could have, and should have, announced the shortened LTS period when they released Node 16, after having already made the decision to ship with OpenSSL 1.1.1. The support period for OpenSSL 1.1.1 was known at the time -- why did it take this long for them to notice and pull back their LTS date accordingly? It could have been known on the day of Node 16's release. The important part of LTS releases is being able to make plans around firm dates; the specific length isn't important as long as it's known up front.
I think to expect perfection in timing and aligning work done by humans, even where someone could make reasonable foresight arguments, is overlooking how challenging this wide level of supporting an ecosystem is.
The response they made is in regards to security and making ut clear to users that they are expected to be anti-fragile to change. Even if the roadmap itself changes.
I've changed decisions, even flip-flopped several times due to uncertainty. When at the heart of the message they are acting with positive intent, I applaud their short, sweet, and to the point message along with their reasoning.
I worked with an organization that allowed TLS 1.1 for far too long because customers systems hadn't been updated. If they paid enough money, we had to allow it. Meanwhile we were getting beat up by the competition because, "Why would any good development company allow this?!?"
Hard agree. As a community we need to stand up for our freedoms and stop using Node for any kind of application, since it's always inappropriate. I'll take you one step further and say that every instance of JavaScript usage is also unnecessary, even for an 'interactive' frontend (spoiler: most people don't care about interactiveness, just look at comments on this site).
As a fun story, I was working in Node with a senior developer with 4 years of experience who wanted to use a library for a trie, instead of simply building one. Can you believe it? I fully implemented one in a half day to show my colleague how unnecessary it was, and we actually found a few issues with the library that my one didn't have.
That's nothing. Somebody tried to get me to use git for source control, but I showed him by taking six months off to write my own source control system.
According to https://nodejs.org/en/about/releases/ (which has not been updated with the new schedule), nodejs 18 maintenance status will start on 2023-10-18, which means there will be a bit more than a month without a maintenance LTS version. It would be nice if they could also advance this date to match the new EoL of node 16 so people that are not interested in backported features can live their stable and regression-free life quietly :)
I don't know why people are complaining that they should have done things differently. 15 months is sufficient to migrate any application to Node 17.
But let's be real, everyone on Node 16 is going to forget about this and panic next August. Then it'll take a Herculean effort by a few heroes in each company to pull off the migration under a tight deadline of a few weeks.
> 15 months is sufficient to migrate any application to Node 17.
If you don't work in tech, it's hard to explain to the higher-ups why some big software upgrade that will result in no user-facing improvements needs to take months off your million-dollar product launch.
Besides, given the turnover these days in both people and frameworks, you're lucky if you're even still on the same stack 15 months later, lol
are node version upgrades a big pain? i haven't used it for anything enterprise level. only hit a few quirks here and there with some deps. i just drop back and wait for library maintainers to fix.... but i guess if you are that library maintainer it sucks
As an aside, what is the obstacle to wider LibreSSL (https://www.libressl.org/) adoption, including node? Have the original SPOF and code quality issues been resolved by OpenSSL?
44 comments
[ 3.1 ms ] story [ 103 ms ] thread[0]: https://docs.aws.amazon.com/lambda/latest/dg/lambda-nodejs.h...
[1]: https://cloud.google.com/functions/docs/concepts/nodejs-runt...
I hope they add Node 18 sooner than that.
> We recognize that customers have been waiting for some time for this runtime release. We hear your feedback and plan to release the next Node.js runtime version in a timelier manner.
https://aws.amazon.com/blogs/compute/node-js-16-x-runtime-no...
Their latest version of Cloud Functions is actually using Cloud Run under the hood already.
Cloud Functions/Lambda are very nice in a company where you don't necessarily have access to making your own AMI, or container image etc.
At least that's what we used them for at my old job. Still had to deal with some level of corporate tech indirection (E.G. We couldn't make the API gateway however we wanted, our account had no access to route53 etc.), but much less than with containers. It was just a quicker way to get code running.
Upgrading from 16 to 18 on Windows or Linux took me like 2 minutes of resolving some conflicts. That same repo took several days of investigation on M1, and eventually I gave up...
If they’d move to LTS a month earlier, not a whole lot of people would gain something from it.
Here’s our choices. Here’s our thinking. Here’s what we decided and why.
Not ideal but it’s still over a year from now which gives folks time to plan.
[0] https://www.github.developerdan.com/node-version-audit/
[1] https://raw.githubusercontent.com/nodejs/Release/main/schedu...
[0] http://web.archive.org/web/20210403090336/https://www.openss... -- this is prior to Node.js 16's release
https://github.com/nodejs/TSC/issues/1222 https://github.com/nodejs/TSC/pull/859
> The OpenSSL 3.0 release schedule is documented on the OpenSSL 3.0 Release Schedule wiki page. We expect the final release to be in early Q4 2020.
Node 16 Release date:
> 2021-04-20
They gave themselves 3-6 months buffer from 3.0 release to Node 16 release, and decided to move forward when OpenSSL was 4-6 months behind schedule, with no idea when 3.0 would release
OpenSSL was then released in SEPTEMBER of 2021, nearly a year late, and 4 months after Node 16's LTS start date.... As of April, the Node team could not know if OpenSSL was going to be released tomorrow, next month, or next year
I think they made the right choice to keep moving forward instead of halting work waiting on OpenSSL to get back on schedule... by April 2021, when SSL 3.0 was already ~5-6 months behind, I would have expected them to extend support for 1.1.1 for another few months... they didn't but that's mostly a moot point -- OpenSSL has committed to security fixes through the Node 16 end-of-life.. but the Node team isn't comfortable with that, so they made a change
It's not impossible. They just have to support more.
I think to expect perfection in timing and aligning work done by humans, even where someone could make reasonable foresight arguments, is overlooking how challenging this wide level of supporting an ecosystem is.
The response they made is in regards to security and making ut clear to users that they are expected to be anti-fragile to change. Even if the roadmap itself changes.
I've changed decisions, even flip-flopped several times due to uncertainty. When at the heart of the message they are acting with positive intent, I applaud their short, sweet, and to the point message along with their reasoning.
I worked with an organization that allowed TLS 1.1 for far too long because customers systems hadn't been updated. If they paid enough money, we had to allow it. Meanwhile we were getting beat up by the competition because, "Why would any good development company allow this?!?"
As a fun story, I was working in Node with a senior developer with 4 years of experience who wanted to use a library for a trie, instead of simply building one. Can you believe it? I fully implemented one in a half day to show my colleague how unnecessary it was, and we actually found a few issues with the library that my one didn't have.
Took advantage of HN's JS based interactivity to downvote your comment. I might not have if the interaction had required a page reload.
See? JS solving a real world problem.
That's nothing. Somebody tried to get me to use git for source control, but I showed him by taking six months off to write my own source control system.
With the canonical schedule you can do an upgrade every 2 years, skipping over every other LTS. eg you could go from Node 14 to Node 18 to Node 22.
But with the early EOL, if you're on Node 16 you can't jump to Node 20, so you have to do an extra upgrade.
For companies with big production codebases it can be a lot of work to qualify new releases.
It would be great if the Node team pulls forward Node 20 LTS by 6 months to preserve the skip-every-other pattern.
https://nodejs.org/en/about/releases/
But let's be real, everyone on Node 16 is going to forget about this and panic next August. Then it'll take a Herculean effort by a few heroes in each company to pull off the migration under a tight deadline of a few weeks.
If you don't work in tech, it's hard to explain to the higher-ups why some big software upgrade that will result in no user-facing improvements needs to take months off your million-dollar product launch.
Besides, given the turnover these days in both people and frameworks, you're lucky if you're even still on the same stack 15 months later, lol
Its a sad reality of web development unfortunately