[kevincox]

You can choose to deny it but you are using a very outdated definition of serverless. The modern definition is that you don't need to think about physical machines. You only worry about the code and running that code is someone else's problem.

I agree that this isn't the best word for it because the etymology is suggesting that there are no severs but language is about how it is used, not the letters that make it up.

Even wikipedia agrees: https://en.wikipedia.org/wiki/Serverless_computing

[JamesSwift]

Thats all well and good but I've taken the same position as OP when discussing with colleagues and they unironically held fast that the serverless model is essentially closer to a functional/pure programming model because its "serverless", i.e. stateless.

[Spivak]

I mean I don't think they're wrong here. When all persistent state is hidden from your code by the runtime you're as close to stateless as you can really get. Sure you can argue that there is state somewhere in the stack but that's always true so it's not very useful to point that out.

[JamesSwift]

Thats exactly my point, and is exactly why I'm pointing it out. The argument from this group of people ignores that the state still exists. The state is not being eliminated, its being shifted somewhere else. A lot of times the process to shift that state somewhere else is not worth the cost.

[flohofwoe]

It does sound like an intentionally misleading name invented by the marketing / PR department of a cloud service provider though. IMHO it would be better to come up with a better name that describes what's actually happening.

[Spivak]

This already exists with FaaS -- function as a service. But then the common usage of "serverless" is FaaS plus all the additional services you need to actually make a real app.

[bserge]

Sounds to me like adding yet another middleman to pay. Why?

[cle]

Because the middle man does stuff for you like emergent OS patching, secure log handling, request routing, TLS termination and cert distribution, zonal redundancy and failover, access control, etc.

[bserge]

I grew up with having to do all of that myself. It's really not that hard, a minor part of running a website/service/app. Why would I give up more control? Just a machine (bare metal or virtual) and the domain are enough... Guess I'm old now heh

[cle]

As a business, you give up control for critical infrastructure to be managed by dedicated engineers who are experts in those areas, who can let you reuse their already-audited and compliance-certified infrastructure so that you don't have to do that yourself.

I agree it's not hard. It's also not hard to accidentally store your logs unencrypted, ruining your FIPS or HIPAA compliance and putting your company in legal risk.

[bitwize]

Used by whom? A handful of marketroids? We're a technical community, ostensibly we favor precise language. We should push back against this sort of humpty-dumptyism, especially the new "descriptive language means you are forbidden to call out linguistic idiocy" kind.

If this is "serverless" then a taxi ride is "carless" and a restaurant meal is "stoveless". There is a distinct semantic difference between "you don't have to deal with X directly" and "X does not exist". Imagine the U.S. having a proxy war by supporting insurgents who bled and died for their cause, and then having the audacity to call it "bloodless" because the insurgents weren't Americans!