It is what it is - and I put a paragraph at the start of the blog for folks who are still confused. It explains that Serverless is a pattern and not a literal term. I even wrote a blog post about it - we've done such a poor job in this industry of explaining it. https://blog.alexellis.io/introducing-functions-as-a-service...

Maybe if a better term is used it wouldn't need so much explaining.

To me, "Functions as a Service" is massively more obvious than "Serverless".

And the cloud would be better as a server somewhere on the internet but terms like this get created because it's easier to sell a one word concept.

Yes... can we all start berating every blog post that uses the word "cloud"? There are no clouds in this server! :-D

It is not to me. Isn't a 'Function as a service' just a... service? Why not just call it a multi server "Platform for services".

Exactly, because what can be considered serverless can wildly vary, such as:

Google App Engine, Google Big Query , AWS Lambda, AWS Athena

The name (which is just a marketing term, not technical) just reflects that you don't deal with servers but with services.

I consider it "serverless" similar to how "stainless" steel only lessens, but isn't a full 100% guarantee. That makes me feel slightly better about the term, ha.

Even more so confusing as the term "server" is currently pretty meaningless IMO (exhibit one: tiny rpi board is also a server).

I agree with you, to an extent. By the same criteria, some PaaS services could also be considered serverless, but the term does not apply to them. However, since the term evokes the idea of "less infrastructure to manage" and, consequentially, "lower costs", it works well to draw the attention of executives.

AWS Lambda is "serverless" to customers. You only pay for running the functions, even though Amazon pays for running the underlying architecture which obviously runs on servers.

Well, the difference between that and running on Elasticbeanstalk would be you choose the sizing while Amazon chooses the sizing for you in Lambda. The reason people seem to advocate FaaS is because Lambda can be viewed as a job sent to queue and then runs based on event criteria (time based or event trigger based). Look at Lambada like writing and calling a job from queue (eg celery).

Nothing fancy about serverless.

I disagree; I find it very helpful.

It's not terribly complicated either - if you are only concerned with code, then your deployment is 'serverless' in the sense that _you are not concerned with servers_.

Of course 'servers' are involved; the point is whether that's of concern to your deployment.

Daemon processes (100% software) also get called "servers".

In an old job, in an effort to disambiguate, I would always use "computer" to mean hardware (losing battle).

I'm not sure that distinction is clear. For example, in AWS Lambda, you still have issues like functions being "warm" or not, and people write code specifically to handle that. Meanwhile, nowadays you can acquire and configure even dedicated machines using just code.

If you have to configure a machine, even in code, then you aren't "serverless". To me, serverless means that you do not manage the machines or even have direct access to them.

What's a machine? :) A dedicated server sure is, but a VPS? An Heroku Dyno? What's the line?

> What's a machine?

I would say "machine" means the hardware and/or the operating system of the "server" (which is a fancy word for "computer").

The "and/or" part being very important!

Fair points. I'd say it's as clear as 'middleware'. When you are trying to get to the limits of performance (or just optimizing), then you tend to start thinking about the platform it runs on.

This is the problem with most abstractions in IT I guess - they're beautiful and clean until reality bites.

Wouldn't that definition apply to services like Heroku as well though?

For sure.

> I don't find it at all helpful when describing application architecture.

If you can draw the application architecture without anything that is best labeled a server, wouldn't that make it a "serverless" architecture?