> So it is about how the user perceives the application
The user here is the developer. Here's an explanation from the article:
> "some amount of server-side logic is still written by the application developer but unlike traditional architectures is run in stateless compute containers that are event-triggered, ephemeral (may only last for one invocation), and fully managed by a 3rd party ... One way to think of this is Functions as a Service."
I also dislike the term serverless. It's confusing, doesn't relay the information it should. I can't suggest a good replacement, but it's painfully obvious that even here, most people commenting don't actually know what serverless means and what its implications are.
Serverless really is an auto-scalable distributed infrastructure, perfect for small CPU-intensive tasks in an app which doesn't know how many CPUs it'll need at any one time.
I think you're misunderstanding. I read it as "they could just as well not be servers". It could be Diamond Age rod logic. It could be processing implemented on quantum foam. It could be gnomes. The point is that from the user's perspective, they no longer have to think about servers.
The whole idea of a server is to abstract away the details of the upstream computer and its software stack, so the user can think of it only as a provider of an abstract service. The irrelevance of their implementation as a host, VM, box, rack of boxes, pool of quantum foam, string and sparkles, is already built into the concept.
We all know that there's no unique process that is http://amazon.com. It's a service, provided by a (vast distributed) server.
I don't think I have ever heard anybody use "server" to mean "lots of servers". Perhaps "web site" or "service" or "cluster" or even "load balancers" depending on whether they want to talk about what they provide or what does the providing.
Since the servers are completely abstracted away, they could have just as well not be - hence serverless.
An analogy escapes me but I sure there are some.