I think vendors will do what vendors will do, and you can choose to buy into that or not. Containers fullfilled their promise. You can today host anything yourself easily, with a single command.

The problem comes when developers start building things without this in mind. I see simple site analytics apps in github, where the docker compose file is a web os services and the repo itself is full of init scripts and the sort. You have redis, mongo, an RDBMS container, an analytics db, kafka, all the kafka tooling like bookkeeper, then you have outsourced auth liek clerk or supabase (when the whole thing is not just some supabase chimera with edge functions and whatever else supabase is supposed to run outside your infra).

And the repo description is: simple, anonymous wesbite analytics. The entire thing is more complex than the thin you want to do analytics for. So you bring that into a cloud, and instead of a container, you are now advised, but both AWS and your HN peers that you need to replace each component with it's cloud version, such as elasticache, AKS, cognito, firebase, whatever.

All of these services as you set up, trap you into overprovisioning. Your DB needs to have 3 replicas or you have no guarantees, your auth needs an entire instance of something running somewhere or unicorns start dying.

By the time you come out for sunlight your bill could pay your rent. So you don't self host, you signup for google analytics.

Everytime I find a project on GitHub, the first thing that makes me close it immediately is whether it has a docker-compose.yaml and if it's a single, sane/dumb, low footprint deployment or a chimera.

So self hosting is alive and well, whether your app is easy to self host, and whether you know how to use just what you need from cloud vendors are different questions.