That's a valid definition but it's just one of many. The Function-as-a-Service has also been called "serverless".
Your definition of "serverless" demarcates on where the code runs.
The FaaS "serverless"[1] differentiates on what part of the stack you don't have to manage the housekeeping for. With FaaS-serverless, you don't worry about upgrading a particular Linux kernel version if you can decompose a computation into a function that runs on AWS Lambda. So, deploy computation to the cloud without the Linux server embedded inside an image (AMI) -- and it seems natural for a bunch of human beings to call that "serverless".
Likewise, the "server" in X Window X11 is the display services to differentiate it from the "client" of a terminal app.[2]
All 3 meanings of "server/serverless" can coexist without confusion and it doesn't seem like terminology we have to bikeshed. Personally, the context surrounding serverless always makes it clear what we're talking about. Is anyone truly confused between SQLite being "serverless" and AWS Lambda being "serverless" because they happen to use the same word?
As for Ryan Scott Brown's definition of "serverless", is there near universal consensus on his criteria?
[1]https://en.wikipedia.org/wiki/Function_as_a_Service
[2]https://en.wikipedia.org/wiki/X_Window_System#Software_archi...
If I think of the most basic, abstract definition of a server I can, I'd say it's a piece of software at a known location outside of the client process, to which a client goes to transmit a message (and optionally have future messages back and forth in the same "session").
I would say Lambda is not serverless because it depends on software outside of the client process, and I know where it is.
X is not serverless because the client process is separate from the server.
SQLite is serverless because my process is calling the sqlite library.
Torrenting initially has a server (clients need a way to find peers) but very quickly becomes serverless.
So I'd say my definition isn't about where it runs, but who is running it and in what context.
That's my thoughts on it anyway.
But you're trying to reduce it down to a perfect singular definition. English doesn't work like that and we'll just end up in contradictions as I will demonstrate further down in my comment.
>I would say Lambda is not serverless because it depends on software outside of the client process, and I know where it is.
Right... and I acknowledged and agreed that your particular definition of serverless doesn't include Lambda. However, I can also explain why others call deployment without-the-Linux-kernel as "serverless". I guess a different chain of memes might have resulted in alternative terminology such as "Linuxless" computations or "os-free" functions but somehow the word "serverless" gained currency.
>SQLite is serverless because my process is calling the sqlite library.
So what if my web browser submits a REST API call to a web server that uses SQLite as it's backend? Is SQLite the "db server"? Yes and no. It depends on which definition of "server/serverless". (Machine location vs os in-process/out-of-process)
If we insist on 1 definition, we will have contradictions.
And if we keep on using catch-all buzzwords such as "serverless", it makes words void of any real meaning.
A clear description of Docker encapsulates it as a container.
A clear description of Lambda explains its relationships with functions and statelessness.
Using a term abstractly, in such a way that it can collide with a word that for all intents and purposes appears to be its opposite [0], shouts to a degradation of language use. Metalanguage is in use within various fields, to make it easier to communicate concepts. Here, using a nonstandard word without clear meaning is pointless.
That this is being discussed is proof enough for me that the word is ill-suited to its task.
[0] "I deployed a serverless stack that serves up information from our database."
Yeah, the thing with using a clear language is that what you say may be wrong. If we grow out of our clarity prison we'll be able to babble any combination of words, and still not be wrong!
No, we will have things that doesn't fit the definition, and we will also have people who use the defintion wrongly.
But that's okay.
That's the whole point of definition, to be able to say whether things fit the definition.
If we insisted the "red" only has one definition, then we can tell that white is not red. And that's okay.
In your SQLite example, no, SQLite does not becomes db server because a server application wrap over it. File does not becomes file server just because it's shared over network.
I have therefore decided to assume you are declaring war on Austria.
No. Not if both parties don't agree on a common definition, one party can "move the goalposts".
It could mean A one day and then B another. Look at all the trouble with TLAs.
Additionally, that's an assumption you're making about what I said - I said no server. Nothing about where the server is
Serverless is client-only code, or even Peer-to-Peer between self-coordinating clients.
There's a lot of stuff that overlaps in this domain, including microservices, containers, serverless, and if we want to talk about them we should use the right terminology.