Not too long ago I discovered the work of a very smart and snarky cloud economist by the name of Corey Quinn. There’s a lot to admire in how Corey delivers content, his perspective on the industry, and his sense of humor. Having said that, I’ve been on the k8s learning curve for a little while now, and Corey’s pretty bearish on the topic.
Corey Quinn@quinnypig
If you run Kubernetes in production, you must be incredibly intelligent.
That’s not a compliment; it’s a requirement.17:13 PM - 25 Apr 2019
Corey is one of many cloud computing advocates taking this position, offered here as an example. He’s not the only one, and I even see Kelsey Hightower, one of the original evangelists for k8s, urging some caution. “Up and Running”, a book Kelsey co-authored, was my introduction to k8s, and I’ve tried to pay close attention to Kelsey ever since.
Kelsey Hightower@kelseyhightowerSo you want to roll your own application platform. All you need is:
Linux
Docker
Kubernetes
Istio
Prometheus
Fluentd
Grafana
Jaeger
Harbor
Open Policy Agent
Vault
Spinnaker and Jenkins
Oh, almost forgot, you're also going to need servers, people, and glue. Bring lots of glue.01:32 AM - 03 Apr 2020
I think all of the above is fair, and I think the point about k8s complexity is hard to argue with. It’s easy for somebody to read expert opinions about this technology and get the wrong signal, because you might be starting with the wrong question. In this post, I’m going to urge you not to begin with the question “do I need docker or kubernetes?” Instead, begin with the question “could we get value from the technical and management practices required to express a Dockerfile? A k8s podspec?”
The iceberg of business value
As my question suggests, I have come to believe that the business process required to write a Dockerfile is more valuable than the tooling itself, and can require much more effort than the actual investment in Docker. Is there scripting in place to automate the build and run processes in a reproducible manner? Are all the dependencies fully documented? Have you followed the 12 Factor App framework or similar? Addressing these questions is where most of the value comes from, and Docker happens to be a particularly successful technology that helps organizations deliver after they’ve done so.
The same can be said about your services. The business and technical processes can go beyond expressing their build and run steps in a Dockerfile and can be extended to expressing their services as k8s podspecs.
Lastly, don’t trivialize that this is a genuine question about value! Maybe it makes more sense for your team to go the way of the Majestic Monolith. Go where the value is regardless of hype. If the technology you want to work with isn’t valuable to the shop you work in, perhaps that’s a signal for you to consider other employment, not a signal for the business to change value streams.
Closing thoughts
As I mentioned, I’m still on the learning curve for these technologies, so please take these words with a grain of salt. My hope is that this post has given you an alternative point of view on value creation in the container and container orchestration space. It’s hard to stay grounded when you’re learning about very hyped technologies, and refocusing on business value is how I’ve learned to cope.
Latest comments (7)
I like to use impedance matching (en.wikipedia.org/wiki/Impedance_ma...) as an analogy for software infrastructure.
To maximize forward progress, the demands of the application and its complexity should align with the feature set and complexity of the infrastructure and tooling to support it!
I worked pretty heavily with Docker and K8s at my last job, and while I like them, I'm semi-skeptical of them. I think for certain classes of systems, K8s is a great technology that gives you lots of really useful things, like auto-scaling and the self-healing "oh, your pod crashed, I'll restart it" feature.
I also believe strongly that below a certain scale, you should not build and manage your own K8s clusters. If you're hosting on AWS, Azure, or GCP, I think you're better off using the provider's own managed Kubernetes service, even if you end up accepting that this may tie you to a specific version or potentially lead to minor vendor lock-in. It's too easy to go down a rabbit hole of ever-shifting cluster setup scripts and application breakage leading to spending a lot of time fixing that instead of focusing on what you're actually building.
K8s aside though, I'm a big fan of Docker and containerization technologies. Being able to make a process repeatable and eliminate whole classes of "worked on my machine" issues is great.
Kelsey Hightower agrees with you:
"Managed k8s" today isn't where Kelsey predicts here, but I think his intuition on this holds. Remember that most of our competitive advantage in this business is from distinguishing "core" versus "context". Managed database services like RDS are successful because everything below the DB app level is "context." In the future Kelsey is predicting here, writing the podspec or deployment spec can be "core", but much of the control plane config in k8s will be "context" for many shops. Offloading it to EKS/GKE/AKS makes as much sense as offloading DBA tasks to RDS.
Having said that, RDS didn't wipe out the "roll your own"/"on-prem" set, so my guess is that both with remain for k8s as well.
That's interesting, I hadn't seen that tweet from Kelsey, thanks :)
I agree with your take here, and I like the core vs context framing here; I know the idea has been around for a while, but I first saw it articulated by Gene Kim in The Unicorn Project last year and it resonated with me - probably because I spent a lot of time working on context because of broken cluster init scripts. ;)
Exactly where I first saw it too. To be honest, I've been working my way through everything he's ever written. Books you may like and have probably already read:
I've heard of all of them, but haven't read them yet. An Elegant Puzzle, in particular, is on my list to check out. I'm not sure engineering management is where I want to go, but having some grounding in it should be helpful and I've found other books on the topic to be relevant even from a senior/lead developer perspective.
Have you by any chance read Camille Fournier's The Manager's Path? Well written and relevant even at the individual contributor level; I should read through it again soon.
Well said. Another smart take on the subject: Workflows, not technologies.