> And then there is Helm

Right, who doesn't want to template hundreds of lines of code in a language that uses whitespace for logic and was never made neither for templating nor complex long documents(YAML)? What could possibly go wrong ("error missing xxx at line 728, but it might be a problem elsewhere").

Lot's of things are nice to have but are expensive.

I'd love to have a private pool in my backyard. I don't, even though it's nice to have, because it is too expensive.

We intuitively make cost-benefit choices in our private lives. When it comes to deciding the same things at work, our reasoning often goes haywire.

Sometimes we need an expensive thing to solve a real problem.

Your point about object-oriented programming makes sense. Sometimes, a bash script suffices, and the person who decides to implement that same functionality in Java is just wasting resources.

All of these solutions have a place where they make sense. When they are blindly applied because they're a fad they generate a lot of costs.

I’ve only ever seen a single dev team managing their own K8s cluster. If by deploy you mean “they merge a branch which triggers a lot of automation that causes their code to deploy,” you don’t need K8s for that.

Don’t get me wrong, I like K8s and run it at home, and I’d take it any day over ECS or the like at work, but it’s not like you can’t achieve a very similar outcome without it.

3-4 services and a bunch of databases?

Assuming there aren’t any particular scaling or performance requirements, if I were managing something like that, I would almost certainly not use k8s. Maybe systemd on a big box for the services?

For personal stuff I simply run systemd services and that does scale quite a lot (as in, you can rely on it for more production services) I believe.

If I had 3-4 services and a bunch of databases, I would look at them and ask "why do we need to introduce network calls into our architecture?" and "how come we're using MySQL and Postgres and MongoDB and a Cassandra cluster for a system that gets 200 requests a minute and is maintained by 9 engineers?"

Don't get me wrong, maybe they're good choices, but absent any other facts I'd start asking questions about what makes each service necessary.

AWS Fargate is popular among large companies in my experience.

Some of them try to migrate from it to a unified k8s "platform" (i.e. frequently not pure k8s/EKS/helm but some kind of in-house layer built on top of it). It takes so long that your tenure with the company could end before you see it through.

Using cloud platform as a service options. For example, on Azure you can deploy such system with Azure App Service (with container deployment), or Azure Container Apps (very suitable for microservices). For database, you can use Azure Database for PostgreSQL (flexible), or Azure Cosmos DB for PostgreSQL.

This way, Azure does most of the heavy lifting you would otherwise have to do yourself, even with managed kubernetes.

In my home environment I run a VM with docker for that.

In a commercial environment I’d still use kubernetes. But maybe something like k3s or if we are in a cloud environment something like EKS.

Usually with time other services get added to the stack (elastic, grafana, argocd, …)

If you use AWS, it's probably easier to use ECS that takes away some of the complexity from you.

Docker compose is another option.