This. 100 times this. Also, in several places most of the services downtimes are due to, you know what? Application bugs, not infrastructure outages. Sure, they happen as well and being on a good cloud provider mitigate a lot of them (but not all of them!) but if you increase the application design complexity you will increase also those downtimes. Yeah sure, there are tens of really good engineering departments where everything is properly CI?CD, automated, they can scale to thousand of services without skipping a beat... but that's not the reality for thousands of other smaller/less talented shops. So, "moving to serverless" will not just automagically fix all of your problems.

Also - and I'm an infra guy so I'm probably biased - I don't really get all this developer anxiety to outsource infra needs. Yeah if you are 2 devs working on your startup it makes sense, but when you scale up the team/company, even with serverless, you WILL need to dedicate time to infra/operations and do not dedicate it to strictly-business-related code. Having somebody dedicated to this is good for both.

You're getting rid of a whole lot of lower stack issues, and I say this as a part infra guy myself.

Yes, Ops will still have stuff to do, it will just be at another level.

It's inevitable, that's why we're not making our own memory cores anymore.

> try rebooting the instances

I haven't done anything with serverless, but surely the class of problems that would be fixed by an instance restart don't happen in the first place on serverless

It was intended more to invoke general ideas about management ease than being a specific remediation, however elsewhere in the thread there is an example of a diagramming tool split out across 37 individual AWS services/service instances. In a traditional design, this is conceivably something where all state and execution could easily fit in one VM, or perhaps one container with the state hoisted off to a managed service. In this case we could conceivably fix some problems with an app like that literally just by kicking the VM

I don't think you're wrong, I just think you're not looking far enough ahead.

What we have now is very primitive compared to how app development might work in the future; serverless is laying the foundation for a completely different way of thinking about software development.

I think I understand your point.

It's more back to the mainframe model of software development. I did this back in the 90s and I never had to think about scaling. Granted these were just simple crud / back-office apps.

But I can see how it would work for most modern software.

The mainframe model is viable (and legitimate) again because you can buy 128 core machines. That’ll have no problem running at people’s businesses

>training an operations team to take over maintenance of a nested spaghetti of random interlinked services and bits of YAML trapped in random parts of the cloud is a total nightmare. The amount of documentation required and even the simple overhead of enumerating every dependency is a long term management burden in its own right.

Upon learning about it some time ago, this was exactly my conception of what a Lambda-like serverless architecture would yield.

And it would seem difficult, if not impossible, for any dev to maintain a mental map of the architecture.

We had a microservice craze a few years ago. What about that, did they all crash?