"A server app could take minutes and would still be okay, because they are designed to run for a long time."

Wby would you want to maintain a long-running server process if you don't have to? And, wny do you think you have to?

There's many reasons why you would want the server, and reasons why you may not want it. Data structures and algorithms that as you scale give you an edge in the specialized problem domain you are in is usually one that I've seen. How many services have I've seen deployed that scale the DB to many cores and CPU's just to avoid some startup time? This is a problem I sadly see in a lot of Node stacks, and its easy to look good when you write a simple component to replace all that complexity and costs decrease as a result.

Most of the "serverless" things delegate to a server in the end anyway - whether they be a database, a managed service, etc. Something has to stay alive, be a server and own the state after all - serverless doesn't make the problem go away just passes the buck. For run of the mill small scale websites or websites that fit a particular paradigm lambda works fine. But it doesn't suit all apps, and its hard to make all problems fit it currently. As businesses scale custom solutions can scale better.

A typical most basic website, awaiting requests and serving static/dynamic content is not a short-living process, I don’t see what is controversial about that.

"[A long-running, traditional server process] awaiting requests... is not a short-living process."

That's an irrelevant tautology; the question was why you believe a long-running traditional server process is necessary.

At the end of the day, most web servers are about serving requests. A short lived function model fits that more closely.

So you think starting up a whole process, establishing connections to a db and serving the request would have any sort of acceptable latency and/or throughput? At that point, you could write your server in bash as well.. also, I think it would be ridiculously expensive.

Lambda is great for seldom run functions, like running some analysis/conversion on user uploaded profile pictures or the like.

Lambda containers serve multiple requests. You just write the code as if you were handling a single request. And on the contrary, Lambda latency is worst when you have spiky traffic patterns (such as for a seldom run function). Of course, if you can tolerate the cold start latency overhead, Lambda is also a cost effective solution for those seldom run functions.

Also, specifically for Aurora, Lambda supports transparent connection pooling. It is just no longer a concern of your application code.

Disclaimer: I work on serverless services at AWS. I’m definitely biased :)

Thanks for the correction! My point was not at all to “bash” Lambdas, just to point out the (in my opinion) incorrectness of grand(grand?)parent’s comment.

Though I suppose Lambdas don’t use separate traditional OS processes to serve requests, do they?

To answer your (intended-to-be-rhetorical) question: yes! NextJS webapps deployed to Vercel / AWS lambdas have excellent performance characteristics.