I would agree and here's why: when compared to PHP scripts of old, the concept is the same. You have some bit of executable code that gets called when a specific URL is hit.
"Don't care where it runs, don't want to manage it, I want to pay only for when I actually use it, thanks for managing it, here's some extra cash for the effort"
But you can only apply that metric if you remove the end users from actually touching the machines (virtual or real).
This is the "less" in serverless.
Turns out that this is also something people want: not having to be on the hook for actually administering machines, installing security patches etc etc.
So managed (platform as a) service + fine grained billing
I would have preferred something like daemonless, processless, or something that more closely describes what's being offered. My suggestions also are flawed but less flawed than serverless, imho.
> Recently, folks have begun to use the word "serverless" to mean something subtly different from its intended meaning in this document. Here are two possible definitions of "serverless":
Classic Serverless: [...]
Neo-Serverless: [...]
SQLite was already "Classic Serverless". Now it's "Neo Serverless" as well.
https://www.sqlite.org/serverless.html