Fight the good fight, you're not the only one standing up against this ridiculous moniker. Never back down. Keep calling out the bullshit every time and everywhere this term is promoted. People ask "what's the big deal?" well the big deal is ,calling a service "serverless" is both a lie and misleading for marketing purposes.
Like when people say that integration tests are unit tests. That gets me going every single time (a unit test is a test on a unit of code, e.g: a function or method).
If you have seen "the interview", this is like when the guy says "on the line", and gets corrected each time.
The name "serverless" will and is likely doing everything I'm sure it was intended to do... provoke curiosity, signal "this is different than just another PaaS", sound cool and maybe polarize or incite those who get angered over technically less-than-accurate names for frameworks. I'm both surprised and not surprised that HN comments have been so relentlessly focused on this seemingly trivial matter. I can understand that the engineer/scientific mindset would likely take issue with this name but I think the "I'm a human that's grown up in an age of omnipresent marketing-fu." part of you needs to realize that all ideas survive and die on the act of finding a place in your brain- a hook so that next time you discuss with someone their need to scale infinitely/instantly without provisioning containers or an IoT device that only needs logic run in the cloud every 5mins you'll be more likely to remember and suggest: "Well there is this framework with a terribly misleading and inaccurate name that may help you called serverless."
The concept of 'server' loses all meaning in this given architecture.
You create 'Lambdas' - units of functionality - and they do that they are supposed to do entirely independent of the underlying architecture.
In fact, using the concept of 'server' in a Lambda situation probably obfuscates the situation and adds unnecessary complexity.
A 'server' is an implementation detail that concerns only those providing the container/Lambda services. As long as the implementation lives up to the SLA (i.e. performance, uptime, security, price, redundancy) that you have agreed to - then it doesn't matter how it works.
All of that is running on a server, connecting to a server, etc.. If this is "serverless", then any random cpanel host has been doing "serverless" php/mysql for 20 years.
