We loved you, Now. But we have to leave you, Now.

Serverless is still bad for modern web apps, that serve HTTP requests to real people..

I know that from practice, running Next.js & a GraphQL backend on AWS lambda.

Many devs think, that the infamous "cold start" problem is easily solved by:

"Warm" keeping (keeping a number of functions "warm" 24x7).

Cold start times getting below a certain level, the often cited < 300ms.

Both solutions currently fail to address the problem.

Let's say you keep 5 functions "warm". Of course the first users will not suffer from cold starts. But then, if you get a large number of almost simultaneous requests (a burst).

A certain number of users will get immediate responses, as they are handled by warm functions. But another set of users will experience far worse response latencies, as lambda functions were spun up, for every additional request coming in, while the warm functions were occupied.

While spinning up new servers is definitely slower, the total wait time in the classical server model, under heavy load, is equally distributed among all users of your app, so everyone sees it perform "a bit slower".

In the serverless model, on the other hand, some users will enjoy the immediate response time, while others will have horrible response times (especially taking additional latencies into consideration, see below). And they will leave your website within those 3 seconds.

For most commercially successful websites, increased latency is far more expensive, than some additional scaling cost. Everyone coming to our app is worth a lot of $$$, as we had to spend a lot of $$$ to get her here. One should consider that, when discussing scaling considerations. I think most people know the famous Amazon study, of 100 ms === -1% in sales. So if you try to argue about scaling cost, please keep your Google AdWords bill close.

Keeping functions warm also feels like the stone age. You're basically just pinging the thing all the time. People are seriously talking about pint-time-distribution-algorithms on Medium, i.e. how often, and at what time deltas you need to ping the thing, to hope that e.g. AWS Lambda is keeping a certain number of functions warm for you. Feels like a mysterious hack to me.

Now, let's debunk this naive latency argument. (I was sold on that, too before i ran a real life app on it).

Obviously you're not using a huge monolith, splitted your app in services, at least backend & frontend. Now, take a look at our user case.

Client →

→ Next.js Frontend (Lambda with Node.js)

→ GraphQL Server (Lambda with Node.js)

→ Prisma GraphQL Server (Lambda with the JVM)

→ Some managed database at GCP or AWS

See the problem? You don't have ONE cold start time. You might have THREE.

And don't forget, this is just additional time added to the:

Request handling time + database calls + data center latencies + client location latency + low client bandwith. This is why you can read comments here, that real people are waiting 5 sec for your page to load.

Also: The < 300 ms is just a best case scenario, that works for Node.js apps. Try to put a JVM app into the chain app (like e.g. Prisma GraphQL which runs on Scala). The results will be far worse.

That's also why the term "global deployments" is just a nice buzz word. Never forget to keep all your stuff in the same datacenter. You can't abstract away physics. You need to know or make educated guesses, who really owns these Zeit datacenters. If you read "Brussels", get your database at Google. If it's SFO, it might be better AWS..

If you're running GraphQL servers with subscriptions, or any other keep alive connections, beware of other issues with Lambda.

We were planning to use Zeit Now for our whole app infrastracture, besides the DB, which was supposed to be managed by Google or AWS.

We were doing serverless and running on AWS Lambda & Now before. And we were facing severe issues with AWS Lambda: Massive problems with cold starts, with user request bursts (e.g. someone posts an article about your app or after running a TV commercial)

While i try to "embrace" Lambdas that, i must admit, appeal to me from a dev experience viewpoint, i'm losing $$$ and FAR WORSE, providing a bad experience to my users.