Deno vs. Node (cold-start on AWS lambda)

Deno is hot. Aimed to solve some of the more painful aspects of Node, Deno has taken the community by storm and a lot of people are looking to replace their Node-based workloads.

For me, I mostly use Node for Lambda functions. I wanted to see if Deno could replace it. Since Deno has a totally different packaging system that means that I have to wait until AWS clients are written or write them myself. There is a Deno library for DynamoDB , though. Combine that with the Lambda Layer that has been created for the community and you I could get started easily enough. But, is it good?

Mainly, is it performant? I started by setting up two Lambda functions, one written for Node and one written for Deno. Each function did the same thing, wrote a DynamoDB record and then read it back. I created a third Lambda, written for Node, that would execute the other two Lambdas at a specified rate. I'd then monitor performance.

Disclaimer

Let's get this out of the way: Node and the AWS SDK are optimized. They've been around for quite a while and have gotten quite good, as you will soon see. Deno and the library used here have probably not undergone the same level of optimization. That being said, I still wanted to find out if it's worth adopting right now.

The Test

I ran the tester Lambda, asking for 5 minutes of calls every 500ms. I assumed that this would allow the runtimes to 'settle' after the cold-start and I could see representative duration metrics. This was my primary concern: what's the p99 duration of the Lambda function execution .

The results are largely what I expected:

The Node lambda would execute around 40ms, which is quite solid. This was with the AWS_NODEJS_CONNECTION_REUSE_ENABLED environment variable. Init durations were around 350ms. Increasing memory to 1024 didn't improve either metric signficanly.

The Deno lambda averaged a 250ms duration. Worse, the init durations were in the 3.5s range. The main reason for this is the Deno runtime currently downloads external packages on cold-start. There are probably some mechanisms to speed this up, but that's for another post.

So, obviously, this is bad. Getting a 6x increase in moving from Node to Deno is not real appealing. But, does this mean Deno shouldn't be adopted?

Conclusion and Thoughts

Deno is hot. And for good reason. If you've ever worked with Node and the node_modules directory you've probably dealt with a packaging system that has a lot to be desired. Additionally, it's pretty insecure by default, allowing any codebase full access to the file system and network. This has been a recurring problem , usually requiring tools and diligent maintainers to catch problems after they've occurred. Deno aimed to solve both of these problems with a de-centralized package ecosystem and a safe-by-default runtime, requiring explicit parameters to enable access to the network and file system. Oh, and let's not forget 1st class Typescript support !

So, with these numbers, is Deno ready? For API Gateway integration, I'd say no. The cold-start and runtime performance just isn't there yet for backing client-facing API calls. But, what about other situations? Backing API Gateway isn't the only use-case for Deno. In a lot of cases Lambda functions are used for listening to event streams, responding to Step Function calls, or just a nightly background data processing process. In those cases, having a slower runtime may not be an issue (other than the additional billing costs). And, this is where a microservice architecture and highly decoupled systems really shines. You could easily adopt Deno for a few functions that don't need low latency; get used to the runtime and flesh out your development pipeline around it with low risk to your overall project (if it doesn't work, it's hopefully small enough you can just re-implement with Node).

Personally, I'm really excited about Deno. Node has baggage and some of that baggage is not easy to carry. It took years before Node was ready for production and adopted in those environments. Thanks to a vastly different landscape now, I think Deno will be in production much quicker. As such, jump in now where you can and get used to it, cause if you're running Node now I'm willing to bet you'll be running Deno in some capacity in 2 years.

Code

Btw, if you'd like the code so you can run these tests yourself, they're available here , as (what else?!) a CDK module.