[ravenstine]

I don't think that's really the point, but the term "serverless" is definitely confusing. It took me a while to understand it.

By "serverless", usually it's meant that your code doesn't need to concern implementing a server on a socket. All you have to do is have your execution return the right value so that the server in the cloud can do the right thing. No need to setup and configure Express/Fastify. Because cloud providers manage the server aspect of serving a web app, your code just needs to focus on execution rather than delivery, or staying alive until the next request is received.

It's still a very misleading term, however. Every time I hear it, I cringe a little.

[tsimionescu]

But that's exactly what the GP is railing against. Trying to hope you don't need to concern ypurself with setting uo the server and thinking about the resources it needs etc is unlikely to be a good idea, or even to work in real terms. AWS Almbda for example only really works if you understand the limitations of the VM and cluster that your code will be running in, and design your system accordingly.

I once worked on a product that didn't, and had ~10s "cold start" latency for any request, because of the size and reliance on lambda. And of course this "cold start" was actually seen all the time, because it was a new niche product that people pnly accessed occasionally, and because it's actually a "cold start" for every concurrent request.

[intergalplan]

> By "serverless", usually it's meant that your code doesn't need to concern implementing a server on a socket. All you have to do is have your execution return the right value so that the server in the cloud can do the right thing.

Jesus, the "they just reinvented PHP/CGI and gave it a cute name" folks were more right than I thought.