Re:I host this blog from my garage
by throwaway894345 on Wednesday December 08, 2021 @10:00AM
(#29485505)
I think we have starkly different experiences then. I’ve been part of several orgs that started out doing it “the old way”, and anything to do with servers was so difficult that it was relegated to a team of experts. Then we introduced Kubernetes and while there was a learning curve, the development teams were able to own significantly more of the infrastructure with the infrastructure experts owning management of the core and a few convenience operators. Stories like this are echoed all over—that’s virtually the DevOps narrative—container orchestration enables development teams to own their own infrastructure with a dedicated team maintaining a common platform.
Moreover, for single-server use cases, Docker Compose eschews a lot of the complexity that Kubernetes brings for HA purposes while also masking over much of the complexity of managing bare servers.
The Kubernetes (and other container orchestrators) learning curve is substantial, but it masks a lot of incidental complexity that operators would otherwise need to understand to do it themselves.
The fact that you're talking about organizations large enough to have multiple development teams which serve their stuff separately puts you squarely in my case #2.
A 50 person company with <10 developers has very different problems.
Re:I host this blog from my garage
by browningstreet on Wednesday December 08, 2021 @12:46AM
(#29481628)
No, but the operation of Kubernetes is clarified by actually running Kubernetes. Hacking.. or “homelab”-ing is doing it for the pleasure or the edification.
From what I've seen, even people without "decades of experiment" find the non-abstracted system easier to understand and reason about than the Kubernetes version. And the difference in ease is dramatic.
Examples where it makes sense include:
1. You need to deploy multiple independent systems with similar configurations. (Even then, consider ansible.)
2. You have to deploy different clusters of connected systems with related, but different, components.
3. You need to scale up and down what needs to be deployed. (Except don't try to use autoscale. That only works in marketing blurbs.)
4. Somebody else has set it up and you never need to actually understand it. (Good luck if you need to debug.)
But there is no reason to introduce Kubernetes because you need a database, a few webservers, front end proxy, failover, etc. And if you are using Kubernetes for that, odds are that you'll save yourself a world of headaches (and potential security holes!) by migrating away. No matter how much the "chief architect" may claim otherwise. I've seen how this plays out in practice.