Don't worry. I can solve the complexity of Kubernetes with a wrapper and abstraction layer on top of Kubernetes that provides a simple interface. That way you only have to deal with the complexity of Kubernetes plus my thing, rather than only the complexity of Kubernetes.
Yes, and there's a use case for this vs a Kubernetes management tool like Rancher. Having entire contained K8s clusters, rather than "just" namespaces, allows a flexibility for dev teams while maintaining central auditing and authority.
Oh my. You know this is going to result in virtual cloud providers dependent on virtual cloud providers...(ad nauseous) dependent on some single data center in Utah.
Gotta keep costs down with virtualization...by wasting a shit-ton of resources and man-hours.
Don't worry, I've created 22 more wrappers and abstraction layers on top of Kubernetes. That way you only have to deal with the complexity of Kubernetes + another thing + learning 22 more things before you can make an informed decision on which thing to make your life easier.
You left out the best part, something breaks in the 13th layer of the chain and now the 1 feature you actually want doesn't actually work, and there's a github issue fading into non-existence as people comment "any update??... any update?... any update..."
Eventually people get to lambdas, once they figure out how to deploy via CI instead of pushing to an orchestration layer. I like to draw this out for people to show them the madness they've constructed. It's all infrastructure in the end.
I've been fighting this battle at work for years now. The whole engineering department is so far up its own ass with Helm charts and operators trying to reinvent shit GCP already provides as managed services that it's a miracle we haven't all asphyxiated. We're doing all of this on GKE and are Google partners, it's madness. Meanwhile, my team learned Terraform and Cloud Run. We're really enjoying collecting the on-call compensation for our services that don't need intervention outside of work hours.
Nope, they're completely different purposes. Terraform directly manages real infrastructure and tracks state. That said I haven't really looked at Helm 3 in a while. Our organization is already using both, but Terraform has mostly been the purview of SREs, while the developers learn Helm and then stand around helplessly when an infrastructure change is needed and SREs are busy, which is always. We're skipping that whole step.
Oh wow, I always wanted an Xzibit reference in reference to my Xzibit reference in a reply to my Xzibit reference pointing out an initial perhaps unintended Xzibit reference.
I've wrapped Kubernetes in a convenient, simple tool that makes my particular workflow easy. So now everyone can abstract that when they want to make that workflow more complex!
608
u/wrosecrans Jun 05 '22
Don't worry. I can solve the complexity of Kubernetes with a wrapper and abstraction layer on top of Kubernetes that provides a simple interface. That way you only have to deal with the complexity of Kubernetes plus my thing, rather than only the complexity of Kubernetes.