[vidarh]

The less pessimistic interpretation is that it's like having someone else be your devops department. Unlike what people like to think, most people running traditional VMs and containers end up doing just as much devops as on a dedicated server (while doing consulting, I'd typically get more hours at higher rates out of people insisting on AWS, because getting an AWS setup right is a lot of work), so serveless is appealing as a way of making more of the devops stuff someone elses problem.

I get your feeling - I like to be able to ssh in as well, but then I see people I've worked for, and realise that to most of them having ssh access does no good, because they don't know how to troubleshoot over an ssh connection, and they don't want to have to know.

To them, losing that flexibility doesn't really matter, because they weren't doing it anyway.

[cs02rm0]

It's more than SSH access that you give up though. You have to bend to the paradigm completely or you're really fighting against it.

For one example, I keep running up against wanting to delay an execution of one lambda from another. There are some truly horrible hacks out there to try and achieve that.

[vidarh]

Absolutely. Frankly I think in a few years time we'll look at Lambda the way we look at people dumping php scripts on a shared server today. It needs a lot of thinking before serverless fulfills its long term potential in those respects.

The irony is that a whole lot of the solutions are well understood; just not in the same environments. E.g. "enterprise" computing went through a whole cycle of building application services for small self-contained components with discovery and messaging in the late 90's that people seem to have largely forgotten as somewhere to look to at least for a laundry list of what kind of services are needed.