Sure, it may be a platitude at this point, but the Kubernetes space is overwhelming, confusing, and Balkanized when you approach it as an outsider, like me.
Addressing Kubernetes purely through a lens of mockery has carried me surprisingly far in my career. I can make ridiculous images or confidently assert that “Kubernetes” is the name of the Greek god of spending money on cloud services. But I’ve decided it behooves me to poke my head up and see what’s going on outside my lane.
So I’m starting what is no doubt going to become a recurring content feature by highlighting just how overwhelming, confusing, and Balkanized Kubernetes is for newbies.
How I made it to 2022 without using Kubernetes
For those who don’t obsessively track my career history, I got my first Unix sysadmin gig in 2006. Since then, I’ve worn a lot of hats, but I’ve kept mostly current with the state of the art in the sysadmin –> DevOps –> SRE world.
One curiosity about the path I took (which, to be clear, I do not recommend to basically anyone else) is that I avoided any serious work with containers, particularly in production. Though it made me something of an aberration, this was a reasonable approach. Containers were fraught with issues in the early 2010s. Many solutions to managing them seemed overly engineered to a borderline extreme degree.
Even now, the cloud native computing landscape is so breathtakingly complicated that my obnoxious business partner sent me a 1,000-piece jigsaw puzzle of this image.
Why I’m going to start using Kubernetes now
Alas, my consulting clients generally use Kubernetes, and it’s hard to avoid encountering a company that hasn’t at least explored it. Kubernetes has become hard to ignore, and I’m not adding a lot of value by avoiding the subject.
As luck would have it, I recently began work on a new production-like service that I’ll be talking about in future weeks. In a refreshing change of pace, I’ve decided to over-engineer the hell out of this and run it atop Kubernetes. This gives me some key wins:
- I get hands-on experience with an incredibly pervasive technology stack.
- The thing I’m building isn’t particularly bound to anything sensitive on my end, so I can be very transparent about my trials and tribulations building and running a production service that relies on containers.
- I get to see how well my Ancient Sysadmin Wisdom holds up after six years away from running a revenue-bearing production infrastructure. (Note: This may turn into a deeply unpleasant surprise for me …)
- As a nice bonus, this gives me a reference application beyond my completely serverless Last Tweet in AWS Twitter client to use to kick the tires on various tools, platforms, and SaaS offerings that generally tend to fall into my lap.
The baffling maze of Kubernetes
As I got started on my project, I asked folks what the current state of the art is for developing against a Kubernetes cluster. The Twitter replies were illuminating.
In total, I got recommendations for 25 different products. Of these, Tilt and Skaffold got 10 and 12 recommendations respectively, which definitely painted them as outliers over other suggestions with just a few recs. Meanwhile, I’m over here just absolutely screaming at the sheer diversity of responses.
Kubernetes has been around for over eight years now. That’s more than sufficient time for best practices to coalesce around the ecosystem — particularly around getting-started questions like “Well, I have an app in containers, how do I get it into Kubernetes and iterate rapidly on that application once it’s there?”
This sharply contrasts with coalesced ecosystems in AWS. If I were to say that I’m tired of clicking around in the AWS console and want something more rigorous to manage my infrastructure resources for me, I’d receive four different options at most — not 25.
It also struck me that a lot of the suggestions I got came from folks working for a vendor in the Kubernetes space. The overwhelming majority of these people are true believers in their company’s product, but they do have a vested interest in my doing things in a way that aligns with their offering.
It’s possible there are fewer unaffiliated programmers offering up solutions because they all know there are a million ways to run Kubernetes. I’m increasingly convinced that any company that’s managed to get Kubernetes up and running in a production environment has encountered and overcome these choices — but the odds that they all picked the same path are vanishingly small. I suspect I’ll find that “we run Kubernetes” translates to “we have a bespoke unicorn that no other company on the planet runs in the same way that we do, so an awful lot of our engineering ingenuity goes toward keeping the metaphorical lights on.”
There is such a thing as too many choices
All I want to know is “How do I get code from my laptop into a Kubernetes cluster efficiently and repeatably so I can do iterative development?” The answers span 25 different possible solutions, without an obvious winner. I have zero confidence that any further questions I’ll have about running Kubernetes as I continue down this rabbit hole will be any clearer around what the “right” path is.
It echoes the problems the major cloud providers have: Instead of offering you a way to build something, they offer you dozens or hundreds, leaving you with the paralysis and anxiety of the paradox of choice.
I look forward to doing my level best to make good choices as this nonsense unfolds…
