Amazon has been behind the curve with its support of the latest versions of Node.js in AWS Lambda. And while the...
cloud provider might have legitimate reasons for those delays -- such as thorough reviews of open source code -- that lag in support can still be a headache for developers.
Unfortunately, developers can only use the specific Node.js version that AWS Lambda supports and can't upgrade to take advantage of new features, including those that boost performance or offer security fixes, that the community constantly releases.
With every other major version release -- all even-numbered versions -- Node.js produces what it calls a Long Term Support (LTS) release. This is a version that the Node.js community will continue to support and to which it will backport fixes and security upgrades, even after it promotes a new version to stable. As of this writing, the latest LTS release of Node.js is 8.11 -- called Carbon -- while the latest current release is 9.10.
After the community develops Node.js version 10, it will promote that version to the latest LTS release in October 2018 -- just six months after Amazon supported version 8 of Node.js in AWS Lambda.
Why AWS support tends to lag
With Lambda, Amazon needs to handle certain tasks that most organizations don't have to do. For example, the cloud provider needs to perform a full audit of any supported languages to make sure developers can't access anything they shouldn't, such as low-level access to the network or anything else that could compromise another user's Lambda application. Amazon needs to thoroughly vet the code from the Node.js Foundation, and that takes time.
The Node.js community moves fast
A year, for example, feels like a long time in the Node.js community because it moves so quickly, but it's a relatively small period of time compared to how long it takes for most other programming languages to discontinue support for a particular version. For example, Python 2.6 was released in October 2008 and only recently lost its official support. Node.js 6, by comparison, was released in April 2016, and the community will no longer support it as of April 2019.
The cloud provider also needs to support older versions of Node.js in AWS, as the community doesn't upgrade some Node Package Manager modules to support the latest versions. What's more, the enterprises that use Lambda for production workloads often don't have the time or ability to migrate their applications to more recent versions. AWS needs to give organizations plenty of time before it sunsets a supported runtime, regardless of the open source community's deprecation plans.
While there are ways developers can run more recent versions of Node.js in AWS Lambda -- such as the use of a wrapper function, like Apex does to support Go -- it's generally not advised. Developers who need a more recent version should instead use AWS Fargate for Elastic Container Service, which they can trigger from an AWS Lambda function. Alternatively, they could run their applications on more traditional systems, such as Elastic Beanstalk.
For developers who don't necessarily need the latest and greatest version of Node.js, there's only one thing to do: wait for AWS.
Third-party modules could break
There are a ton of new features in Node.js 8, including a new form of asynchronous hook, which some modules depend on. While the community will officially support Node.js 6 until 2019, some package maintainers will not support older versions. This means developers must switch to continue to use third-party libraries, such as Chromeless, which only works with Node.js version 8 and newer.
Keeping up with competitors
The biggest danger right now for AWS Lambda is that many of its competitors, including Microsoft Azure Functions and Heroku, all support newer versions of Node.js. Additionally, some of these platforms support more languages, like TypeScript, which developers can compile down into Node.js. Although this means developers can technically use TypeScript for AWS Lambda, Azure's native support for the language makes tasks, such as debugging, a much more seamless experience than on Lambda.
AWS has, however, improved the speed of its releases. For example, it took the cloud provider almost three years to upgrade from Node.js 0.10 to Node.js 4 but only about a year to upgrade from Node.js 6 to Node.js 8. This certainly shows progress, as well as AWS' response to community pressure to keep up.