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.
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.
Or do you mean that the user don't have to care on how to configure the application? Then "Zero-configuration" is a better name.
Or do you mean that the application hides that it use services on the net? Then it is even worse.
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."
FaaS is probably a better name.
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.
That's a weird logical leap.
Let's make the servers not be by unplugging them. How's the abstraction working now?
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.