Well, if that's true, that's where young software engineers have gone wrong.
The giants among us used to talk specifically about the power of doing the simplest thing that could possibly work: https://www.artima.com/articles/the-simplest-thing-that-coul...
i constantly have to ask the “kids” at work: do you need this? what tps do you need to support? how are you going to maintain this (at what cost)? do you really want to reinvent the wheel?
constantly. i am afraid that most people nowadays practice resume driven development.
my favorite pet subject is k8s.
k8s has its use cases, but i am always baffled by people refusing to use the abstraction the cloud they leverage provide (things like vms, load balancers, autoscaling groups) in the name of using some hot new tech and some benefits that are not clear to them (again nothing against using it if you understand it and fits your use case, but this is not what I reach for as the first thing)
If you've got a legacy application that doesn't play nice in containers, I get why you would stay away, but if you're writing something new- it's so easy to take advantage of K8s.
If I can get away with a serverless service why bother with k8s?
If I can run my service inside a VM and front the service with a LB, why bother?
I think your argument is that K8s adds a lot of complexity, but that's just not true if you're using a managed service. If all you need is a couple of workers and ingress, you're set up in a few minutes
so what are you actually using? containers?
> And if you ever have a need for more than that- you're ready. If you ever need more than that you can evaluate it at that time. K8s is creating the maintenance nightmares of tomorrow today.