This immediately reminded me of Helm charts (Kubernetes) and their implementation with Go templates, that work in the syntatic level instead of semantic, which makes it unnecessarily hard to operate it.
It disturbs me that Helm templates became a defacto standard for k8s. Something went very wrong there.
If you're not doing a unicorn style deployment (100% of users) then you're SOL.
K8s is probably the best/closest thing we have to a workable service "package manager" for server environments. It's a fairly reasonable way of packaging and deploying random stuff to random servers in a sustainable and secure fashion when all you're trying to manage is a small dev pipeline or a prototype/homelab type setup. Instead it feels like the community is trying to skip right over some of the most beneficial use cases for the tech and go straight to nonsense unicorn land.
I think the issue is that for almost everyone tens of servers is the sweet spot. Most teams and even most companies don't need to manage more than tens of servers (how many teams even in large companies actually use or even touch more than 100 servers in prod?)
But kubernetes can scale to thousands.
The leap past those 2 orders of magnitude chnages the game and makes the seeet spot out of reach for the majority. It's like we are taking F1 racing cars on our daily commute and stopping off for groceries
No for almost everyone one server with some packages installed is the sweet spot.
> What if it goes down?
You users will survive a little downtime, if it happens at the right time they wont even know
> But containers
For this use case? A solution looking for a problem
> Why?
Don't be a company with more servers than users
For most it really isn't.
For single node deployments of containers, Docker Compose has usually been enough.
For multiple node deployments, Docker Swarm (possibly with something like Portainer) has worked well for years: it's easy to create clusters, they don't require much in the way of resources and running workloads is pretty simple, definitely in part thanks to the Compose spec.
Of course, there have been issues over the years (CentOS 7 I think needed masquerading for networking to work properly back then) and people might be conflicted about some things - personally I love my "Ingress" being just a web server container with whatever configuration I give it, others might want Traefik or something else, whereas more advanced use cases like task scheduling and replicated storage across the cluster don't have anywhere near as many solutions as Kubernetes does.
Then again, none of those are a deal breaker for me. Of course, something like Podman can also be considered, or maybe Hashicorp Nomad if you don't mind HCL.
I don't know much about k8s, but this reaction reminds me very much of how I felt when I first learned CMake. "Wait we're replacing all this crap with.. this crap?"