I’ve updated the topic to clarify that I meant to discuss serverless in the scope of cloud functions and the architectures which are born out of that.

Cold start is indeed an interesting topic, @dimitarvp, but I think the discussion requires a bit more nuance than “faster cold start is better” and “native binaries start faster”.

You might for example be surprised to hear, that NodeJS seems to have better cold start characteristics than go - and that on all major cloud providers (AWS, GCP, Azure). In general the cold start characteristics of NodeJS rank among the fastest in languages commonly used in cloud functions.

And as mentioned before, faster cold start isn’t necessarily better. If your cloud function is consuming messages from a queue to send out emails, or write into a DB or an S3 bucket, or call a remote API, then cold start characteristics become pretty much irrelevant. Of course, when you actually want to run your API through the usage of cloud functions, then yes, cold start becomes important.

I’m not trying to say “use JS for all the things!” - I’m not that fond of JS myself. Instead I think that serverless - and cloud functions - is an interesting new pattern where seemingly important topics (startup times etc.) suddenly become a lot less important, depending on how you design your application.

If you ask me, I think the serverless paradigm has a bright future wherever you might want to “glue” out-of-band things together or where you have to handle ludicrous traffic spikes. A great example is Square Enix which used AWS Lambda to offload image processing for screenshots taken in Dragon Quest X, which experiences 20-30 times the usual traffic a few times per year.

TL;DR or in a nutshell I think that cloud functions, and by extension serverless, can allow us to build applications, or parts of a larger application, with characteristics usually reserved to much more complex deployments.

Will it replace “old” deployment strategies? Hell no! But will it become an interesting new tool in the deployment toolbox? I think yes.

Resources

• Comparison of Cold Starts in Serverless Functions across AWS, Azure, and GCP
• AWS Lambda Cold Start Language Comparisons, 2019 edition

I feel @AstonJ is spot on in his analysis.

To answer @wolf4earth, I don’t have a personal experience and I am cautiously optimistic. It can be seen as a fad especially when you see youngsters immediately jumping to use it… with Node.JS CLI apps.

Cold starts can be a serious problem. So languages that compile to native binaries – and don’t carry a huge runtime with them that needs a bootstrap on every app start – have an advantage. Off the top of my head, people had positive experience with “cloud functions” in C, C++, D, Rust, Zig, Golang, Nim, OCaml, Haskell, likely others as well. Not so great luck with dynamic languages, Erlang/Elixir included – JS and Ruby weren’t in great shape either, Python and PHP are also rather slow to start.

I’m open to the idea but I’d think that you have to reshape your app and services – likely even your business – to make serverless [cloud functions] work well for you.

One area I am hugely skeptical is that the big vendors will do their absolute very best to lock you in their garden. So the idea is good but I feel is being weaponized for business interests.

That, plus many people really love their JS and don’t want to learn languages like C/C++, Rust or OCaml, which have one of the very best startup times: <4ms for a hello world program. So in the end I posit that the idea might die simply because the JS runtime (Node.JS) can’t be made to start so fast.

I’m sorry to be this blunt: but have you actually read the article?

It mentions this, yes, but only to differentiate it from a warm start where reuse happens. The measurements are explicitly about cold start.

Here is the full context:

When Does Cold Start Happen?

The very first cold start happens when the first request comes in after deployment.

After that request is processed, the instance stays alive to be reused for subsequent requests.

And then further down (before the actual measurements):

How Slow Are Cold Starts?

The following chart shows the comparison of typical cold start durations for common languages across three cloud providers

Again: have you read the article?

Go is actually one of the languages measured. Go is actually measured in both articles, and in both articles it’s measured cold start times are slightly worse compared to JS.

I’m not trying to shill for JS here. I was quite surprised when I first learned about the low cold start times of JS. But the facts don’t seem to support the general statement that “languages that compile to native binaries have a faster cold start”, at least not in the case of JS.

I think it actually shows how much crazy optimization work must have been done on the JS V8 engine and on the cloud provider’s side to enable these times.

Doesn’t mean that I would opt for using JS for cloud functions but it’s impressive nonetheless.