[Herald_MJ]

No, I'm not peeved by the "misnomer". What is getting a bit annoying is every conversation about serverless being dominated by snarky comments about there being no such thing. As software professionals, we all know there is a server involved in responding to requests for our applications. But 'serverless' does accurately describe services like AWS Lambda, 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.

TL;DR: It's just a name. Get over it.

[voidr]

> But 'serverless' does accurately describe services like AWS Lambda,

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.

[Herald_MJ]

> It's a useless and confusing marketing 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.

[voidr]

> 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.

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.

[dvfjsdhgfv]

Ad hominem comments are really unnecessary. Your statement "Serverless is not a buzzword because it is the name used for a collection of technologies" is not logically true. There are many buzzwords referring to collections of technologies, and "serveless" is just one of them.

[dvfjsdhgfv]

"Serverless" is definitely not an "accurate description of AWS Lambda", because the work is done by servers. As the parent mentioned, it would be a much more accurate description of P2P services/protocols.

[zdkl]

> 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.

But didn't we get "The Cloud" to do that? I mean I'm fine with rebranding but this is a really fine line.

[_vufv]

No. The Cloud is used to collectively represent all kinds different types of computing/storage/auxiliary services that can be managed on demand.

[zdkl]

Notice how you didn't use the term server to describe "The Cloud"

[simplexion]

I think something like "Server-nescient Web Application." Marketing departments should like a fun word like nescient.

[le-mark]

Agreed, it is very annoying, maybe 'serverless' isn't the best name, but 'adminless' is no better. All the banal comments about the name have really impeded discussion about this topic.

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.

[mgkimsal]

As with many positions, there's a middle ground. I don't expect people to be able to dive in deep in to the innards of MSSQL and understand all the nuance between types of indexes and how different hardware choices can impact said index types. However, when working with "sr software engineers" who are responsible for SQL, I do expect someone to be able to set up a local test database and create some tables with sample data to demonstrate an idea (in whatever tech they choose).

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.

[marktangotango]

I've seen one team of devs in particular do a really nice job with their sql database, but more often than not dev teams trash their schema and databases, if they're using sql at all. They create rdbs that are not normalized, don't have foreign key constraints, too many indexes (index on every column to get this dashboard query to perform! I've seen this a sad number of times).

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.

[mgkimsal]

No doubt there's a potential for abuse, and there's middle grounds to be had. I've also caught hell from a PM for a project being 'late', even though I had 0 control over actually getting DB changes in, because the DBA was a) on vacation, then B) sick, then C) backed up on other work. But apparently, it was my team's fault that the project relying on a SQL database was not launched "on time" (a deadline I had no hand in making, nor did I agree to either).

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.