I think I will always struggle to understand the popularity of the term serverless.

From the two definitions found in https://www.sqlite.org/serverless.html

classic serverless --> "embedded database" exists and is often used

neo-serverless --> I suspect that this is a marketing term used to attract cool people to new cloud offerings (like "jamstack" for services such as netlify). There is no good replacement here because the term was tied to this new kind of infrastructure really early. But anytime I hear someone repeat "of course serverless does not mean there is no server!" I die a little more.

Naming things is hard but at least we ought to try to come up with terms that are not blatantly misleading.

Look, the industry has settled on the term "serverless" to mean: "You just upload some application code and the system automatically provisions servers to run it."

No one has the power to change this. It's like saying "I think the word 'spoon' is stupid, let's all call it 'scooper' instead." This is our language now, it is what it is. Vendors offering serverless solutions have to call it "serverless" whether they like it or not because that's the word customers understand. You can keep complaining about it, but it won't change. You might as well accept it and move on.

"Cloud" is a stupid term too, your servers aren't really floating in the sky. But here we are.

If only somebody would come up with a Common Interface for application Gateways that would let the webserver dynamically select based on URL routing which executable to provision temporarily to generate that page.

CGI is in no way more understandable than serverless as a concept, especially when it shares its acronym with the very popular computer generated imagery.

At least it's not made out of an English language construction which is actually just wrong.

The english language has a bazillion "wrong" constructions. What is this, kindergarten? Serverless clearly has gotten a specific meaning in the industry, which means "without manually spinning up servers".

And this is how the English language has become what it is. If someone politely points out that the use of a word is incorrect, instead of thanking and correcting themselves, people just shrug and say: "it is what it is" and continue to spread the incorrect usage. I even wonder why bother with grammar in a language like this.

It's jargon used by part of the industry. It's not like the usual irregularities of natural language. There's no need to encourage its wider adoption.

> The english language has a bazillion "wrong" constructions.

Sometimes I complain about some of those too.

Personally, I'm looking forward to the next loop around, when the concept is rediscovered again. It will need a new name. Unfortunately, that's probably going to be 20 or 30 years.

I think the idea is that if enough of us push back, then people will stop using that term. After all, "the industry" is made up of people whose minds we can attempt to change.

The "industry" is comprised of much more than techies -- there are millions of marketing people out there who get hyped up at the shallowest sounding buzzword and we absolutely never will out-shout them. Nor do customers who love buzzwords.

Buzzwords can be fickle things. “Wireless” used to mean radio. Who calls the internet “the information superhighway” anymore? “Computer” used to be a job title. How many job ads capitalise “PC/MAC” even though it’s a contraction of Macintosh and not an initialism like Personal Computer is? The first “tablet” I bought was a Wacom — an accessory, not a computer in its own right. When did we stop calling pocket computers “PDAs”?

"Digital" used to mean something that related to fingers or toes. Then it meant "electronic". Now it means "distributed via network instead of physical medium", even though it's the first "D" in "DVD".

It's not just marketers. The vast majority of engineers are just fine with this term. The set of people complaining about it are a tiny minority.

I'm the lead engineer on Cloudflare Workers. We didn't originally call it "serverless", but after talking to lots of engineers who said "Oh so it's serverless?" we decided to go with that term. The decision was not made by marketers.

So network effects. And the other engineers already bought the marketing term and are implicitly pressuring you into using it. Ouch.

There's nothing "ouch" about it. People understand a term to mean a thing, we are doing that thing, we adopt the same term, now everyone understands what we're doing. Communication is good.

Well, I agree on that. But I do get sad sometimes about how easily influenced the people at large are.

And I'm telling you that idea is not remotely realistic. Sorry.

Then it's similarly unrealistic to expect that some fraction of people who are familiar with English won't continue to complain about it.

<something>“less” has been in use for a long time and typically means a paradigm shift in how the <something> is performed. Horseless carriages still had means of locomotion; driverless cars will still have a means of effecting driver functions; eggless recipes typically have some other substance to perform the job of eggs. In my mind <something>”less” is not as objectionable as <something>”-free” like “sugar-free” which isn’t to say that something isn’t sweet, but that the sweetening comes from something else.

whereas "sugarless" means its not sweet :)

but "sugar-free" means it's sweet again

I really thought we'd have grid computing, aka utility computing. Running our self-contained software agents, persisting data and state in ubiquitous tuplespaces.

That's my excuse for being so slow to grasp "cloud". When AWS made EC2 public, I really didn't understand why anyone would want to use it.

Cloud era "serverless" just pisses me off. The applicable cliche is "Every sufficiently complex C project recreates LISP, poorly."

It's seems like we're doomed to repeatedly reinvent the past. Championed by youngsters who never read the book.

Maybe this explains "worse is better".

I know, I know. I've become the old crank. All you noisy kids get off my lawn.

That's Greenspun's 10th rule. The full version of which is, "Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of CommonLisp."

Robert Morris' addendum is, "Including Common Lisp."

If you don't believe Robert Morris, tell me what LOOP does. :-)

(Note, this is the Robert Morris who wrote the first major internet worm, cofounded Viaweb with Paul Graham, and cofounded YCombinator, again with Paul Graham.)

I wouldn't be surprised if the term originated as a marketing tactic (e.g., AWS) to seed in people's heads the idea of not having to care about servers

You hit the nail on the head. It is all about marketing for the new front-end developers who don't want to learn "server side" manipulation db, files, etc.

Personally the whole indexdb, localstorage really break the web page as a stateless model. Why do you need save so much local data to just maintain the session? Stop putting everything in the web browser.

I can see the value of serverless in general (not this hack necessarily) in small startups that don't have sysadmins on payroll but still want to rapidly deploy products with confidence that it will just work - all without worrying about infrastructure, scaling, etc.

What I'm curious is if (1) serverless is cheaper than hiring competent sysadmins who can maintain the infrastructure instead and (2) are these savings worth being locked into a chaotic architecture and boring proprietary tooling that is forced on you for the profit of the Google, Microsoft, and Amazon monopolies?

I've recently entered the job market and personally find no joy in working in serverless environments because of the latter.

Personally I suspect that the chaotic tooling will waste more dev time than what the sysadmin time will cost you. So that it will be a net loss even before you consider lock-in and fees.

While a good argument in favor of the vendor locked-in serverless services can be made at the start of a project, it looks like a net loss during any other phase of the project.

It comes down to if you want to have generic and reusable sysadmins vs. cloud serverless specialists.

Heroku fits the bill for me. Very easy to manage and scale, still cheaper than an SRE or sysadmin.

You don't need local state to maintain a session other than possibly storing a Token, but that's very small.

Storing data locally is often out of convenience or possibly for cached data for offline support.

There are valid reasons for maintaining local state.

> Why do you need save so much local data to just maintain the session? Stop putting everything in the web browser.

I guess that's to replace the traditional desktop application with something that can be deployed over the web?

Stateless was gone with the invention of cookies and authentication.

I think I heard it first wrt GAE, but I think it was more "wry observation" then than actual "thing".

> I think I will always struggle to understand the popularity of the term serverless.

AWS marketing is very good.

Serverless was a creation of the AWS Lambda team / AWS marketing department "I helped start the serverless movement..." from the LinkedIn of Tim Wagner (https://www.linkedin.com/in/timawagner/)

the difference between serverless and managed service is actually that when there are no requests the serverless is offline and not costing you much.

All this serverless talk is just marketing speak for limited shared-hosting environment.

I think the term is just fine. For me it doesn't mean that there is no server involved to run the app, it means I'm not involved to run the server.

Serverless is an adjective so you can slap it everywhere.

Worker-based or FaaS (function as a service) don't roll off the tongue that well.

I'm not advocating for the term, just trying to explain why it is so popular.

Also, serverless solutions like DynamoDB or S3 aren't compute, so worker based and FaaS would simply be wrong.

They probably call them serverless because you are mainly billed by the number of requests instead of the number of hours it runs for (although for Dynamo, there is a cost per table and r/w)

Would we lose any meaning by just calling DynamoDB and S3 managed solutions, like in the old times?

EC2 is a managed solution but you still need to manage servers.

Elasticsearch and RDS are also managed, but not serverless.

That’s kinda unrelated. The title here could have been “SQLite in serverless apps” or something to avoid the confusion.

And https://en.m.wikipedia.org/wiki/Web_SQL_Database which was truly serverless SQLite for a web browser.

How is the OP not "truly serverless SQLite for a web browser"?

SQLite has a stricter definition of serverless than conventional.