That's exactly the argument why you should go serverless. If all you do is keep a vanilla Linux distro running in a VM with occasional updates and some initial config-magic (webserver, certs, ip tables, ssh etc.) why even bother? The serverless isn't going to be any different, other than it just runs. No need to make a cron for updates, no iptables, no certs or webserver-stuff ... just put your app on it and let it go. On the other hand, if you actually need to tinker with your OS, roll your own. But what you described is the prime example of serverless target audience.

One reason serverless isn't the solution for most applications is that you're basically making yourself entirely dependent on the API of one specific cloud host. If Lambda decides to double its price, there's nothing you can do about it but pay. If you need to store your data in a specific place (for example, in Russia, because all Russian PII must be stored in Russian borders), then you're out of luck. And best of luck to you if you're about to catch a big customer but they demand your application to run on their premises.

There's also the long-time guarantee; if you write an application that runs on Ubuntu Server or Windows Server now, you can bet your ass that it will still run, unchanged, for another 10 years. The only maintenance you need to do is to fix your own bugs and maybe help out with some database stuff. If you deploy a Lambda app now, you have nothing to guarantee compatibility for such a long time other than "Amazon probably won't change their API, I think".

You can also predict the costs, and shop around if your provider gets greedy. If Amazon changes its pricing structure, what are you supposed to do?

If you built everything in proprietary infrastructure, porting is a lot more work.

Using lambdas tie you to AWS because as soon as you use a few step functions, or you have a few lambdas interacting, changing to Azure or GCP becomes a huge pile of dev work and QA.

Having everything "just run" on linux instances let you be perfectly portable and now you can actually shop around.

It's a lot easier to change providers, if your service is an (eg.) docker image(s), than to move something relying on amazons api.

It's even easier if your application is just (an equivalent of) a binary, or a tarball.

Unless it relies on any system libraries, in which case you're in dependency hell when you upgrade or change the OS.

This is a solved problem, and dependency hell happen when not choosing dependencies wisely when creating programs.

Because you can reproduce that environment locally. Often useful for fixing bugs.

Also useful for doing the development in the first place!

Kubernetes, microservices, distributed systems, SPA apps. Getting a development environment to reproduce bugs takes up so much of my time these days (a fair bit is because of our crappy system, but there also a lot of inherent complexity in the system because of the architecture choices listed above). We get the promise of scaling, but most places making these choices don't actually need it.

The above comment was intended to answer exactly that: because it is much less maintenance in the long run.

Had you deployed an application to a proprietary cloud platform ten years ago, a handful of those services would have had their APIs changed or even been sunset by now.

Yeah but those "very specific circumstances" can come up at inconvenient moments. Certbot didn't run, disk got full, CPU hitting 100% for some reason, Debian needed to be upgraded, These are all things that need to be taken care of. Sometimes, right away and just when your family needs you.

I agree that it almost never happens, and that's why I run Debian as well. However, if you run production then things happen.

Just like when something unexpectedly breaks due to a component of the serverless environment that has been changed slightly causing your system to break, only then you have even less control when trying to debug the issue