TL;DR: It's just a name. Get over it.
TL;DR: It's just a name. Get over it.
Serverless means no server, which is false, because there is a server that runs your code.
> because the experience of development is such that you don't really have to think about servers, along with all the complexity of provisioning, configuring and managing them.
That sounds like you are talking about 'web hosting' or 'application hosting', which existed decades ago, don't see any point in inventing a confusing buzzword when we have perfectly fine terminologies already.
> TL;DR: It's just a name. Get over it.
It's a useless and confusing marketing buzzword that makes having intelligent conversations harder. I would love to understand your rationale for defending this confusing buzzword.
A marketing buzzword is something like "web scale", which might be used by a non-technical person to describe a technology, but has no real technical meaning. Serverless is not a buzzword because it is the name used for a collection of technologies, even if it isn't a specific product. "Software containers" also falls into this category.
Yes, serverless architectures involve servers. Well done for recognising this, you are very smart. In fact, you are smart enough to realise that the architectures we are talking about here are very distinct from traditional web hosting services. So, it's convenient to use a different name for them.
Finally, it doesn't really matter whether you like the term or not. It is the accepted term and it is here to stay. If you want to engage in conversations on the topic you will need to move past your misgivings.
What collection of technologies does it name? And how is that different from "web scale" technologies that is also a group of technologies?
> Yes, serverless architectures involve servers. Well done for recognising this, you are very smart.
If you would have strong arguments, you wouldn't need snarkiness.
> In fact, you are smart enough to realise that the architectures we are talking about here are very distinct from traditional web hosting services.
That's the exact opposite of what I've said, if you look at it from a server management point of view, traditional web hosting and "serverless" are one and the same, both are used to run the code you upload and both are managed by someone else.
> So, it's convenient to use a different name for them.
It's not convenient, it's confusing.
> Finally, it doesn't really matter whether you like the term or not. It is the accepted term and it is here to stay.
Accepted by who?
> If you want to engage in conversations on the topic you will need to move past your misgivings.
If you want to engage in conversations on any topic with anyone, you should read what's on this website https://yourlogicalfallacyis.com/ and stop doing them.
But didn't we get "The Cloud" to do that? I mean I'm fine with rebranding but this is a really fine line.
I personally am angered at the 'everyone should be a sys admin' culture we've come into as a profession, it completely trivializes the role of sys admins who are critical to any product/company. Good sys admins bring a lot to the table, just like experienced DBAs.
Edit; wow either everyone really hates sys admins and dba's or prefer "adminless", any down voters care to explain?
In truth, I don't think the name 'serverless' will stick in the long term, there is just too much animosity for it. The useage here by AWS is the first time I've seen it in a couple of months. Anecdata, but I think most would admit it's not very common.
I would argue that "sys admins" - in the form of dedicated personnel - are not "critical to an product/company". I know plenty of smaller companies who are successfully bringing in profits, making payroll, etc, but do not have any sysadmins employed. At some point, they will need those skills (and probably stronger DB skills) but these aren't always critical to every project/company/org. Perfect is the enemy of the good.
EDIT: middle ground.
Yeah sure sys admins and dbas aren't critical, but if an organization values what they can do, they can multiply the productivity and effectiveness of the app and product teams.
Specifically, features are faster to implement because the schema is not jacked, the app is responsive and stable because the data is normalizesd and indexed for the access patterns, data is consistent. Customers are happy.
Similar for the network/server side for sys admins.
The policy of "only DBA can make any changes to anything, and all schema changes have to be discussed, reviewed, vetted and approved by DBA" has benefits, in some situations, but also problems.
I had a DBA question why I needed pagination. "No one has ever asked for it before, and never needed it, and I think you're building your application wrong if you need that". After a few weeks of contentious meetings, we got hand-rolled stored procedures for each specific table/query, but they also took days to get to us.
But, hey, you know... at least the tables were normalized and we had "proper" indexes. We just took weeks to get done what should have taken a few hours to prototype (because, during the time we were building the tool, the team we were building it for ended up buying some third party service because we were taking so long).
We've all got war stories of incompetence on all sides (dba, dev, pm, whatever). This is why I advocate "middle ground". I trust a DBA who's actually done a bit of raw coding in their life. I trust a developer who understands the basics of SQL and DB workings (again, 'basics' are fine). I trust the estimates of a PM who is engaged with the team on a regular basis. I trust the views of a business analyst more if they actually show up to meetings and listen to the parties involved.