[jchw]

I disagree. If you build a good enough abstraction, you can give developers a lot for free without needing them to understand. Current serverless platforms are wasteful, but the underlying concept is not inherently wasteful, and I think that cloud providers and serverless software platforms will improve over time.

[marenkay]

The need to understand is a primary skill for a decent engineer. Was in the 1960‘s and still is today. Lack of Knowledge is what makes an engineer a business risk.

[jchw]

I don't need to understand metallurgy thanks to processors. I don't need to understand instruction set architectures or assembly language thanks to programming languages. When abstractions truly separate concerns, they make it very much possible to not understand, much to the benefit of the programmer, who now needs to keep significantly less in their head. Aren't you glad you don't have to be concerned with making sure your stack stays balanced thanks to scoping in C? Well, I'd like to write an API without having to be concerned about job scheduling, dispatching, logging, monitoring, etc. Understanding these things may make you a better programmer (or they may not,) but not having to understand let's you let go of things you don't need to care about and focus on what you're trying to accomplish instead.

We as programmers love writing solutions to problems that have been solved hundreds of times. How many node.js http frameworks exist? Or JS frameworks for that matter? But the thing is, for the most part, when it comes to API servers, there's a crazy amount of overlap between what they need to do. They handle HTTP requests and spit out a response. Someone has written this better than you can, so you use an HTTP library. You probably want to serve multiple endpoints on one port, so you route with the URL. What do you do, implement a radix tree, or use a mature, well-tested, high performance library? If you are sane, probably the latter.

All serverless is is a realization that most HTTP servers don't need anything special in terms of routing, scheduling, monitoring, etc. By turning an HTTP server inside out, you can allow the developer to focus on exactly one thing and give them a platform that is stable and inherently scalable by virtue of being stateless and making scheduling an implementation detail.

If you have a very efficient engine to execute functions, and a very robust and scalable HTTP server, and you can write your app logic to be stateless (locally, anyway,) there's no reason to believe that the serverless approach would be any technically worse than the old school approach.

I feel likewise similar about static files. I don't need to write and operate yet another static file server. I can use Amazon S3 + Cloudfront, or Firebase, or GCS, or any other solution. It doesn't mean I don't know how. It's an admission that I have no special requirements, and would like to focus on the things I'm writing that are particular to my app.

What's dangerous? Not serverless, for sure. What's dangerous, is programmers implementing everything from scratch because they can, doing their own operations when they don't have the resources to.