Thinking of managing Kubernetes yourself? Don’t.

Oh, sure, you’re really smart and could likely pull it off, but given how fast Kubernetes development moves, do you really want to do that to yourself? Particularly given the ultra-convenient Kubernetes cloud services out there?

No, really, don’t

According to a December 2017 CNCF survey, plenty of companies choose to run Kubernetes on-premises (42%). Even those running it in the cloud, however, aren’t necessarily using a service like Google’s GKE:

The question is “why?” As Gravitational’s Abraham Ingersoll noted in a recent blog post:

The absolute safest place to run Kubernetes application is still Google’s GKE. They created it and Google’s SRE culture wrote the book on successfully running large-scale distributed systems. With GKE and similar Kuberentes “platforms,” you can’t touch most of the interesting knobs and buttons that control your clusters. You may eventually pay the ridiculous public cloud bandwidth egress tax. So buyer beware, but BUY NOW.

SEE: Quick glossary: DevOps (Tech Pro Research)

And you may be locked into one of those cloud services. The alternative, however, is potentially to be locked out of full Kubernetes value. Why? Because Kubernetes is hard.

It could be worse

“There’s a strong bent toward keeping the upstream project as flexible as possible for as long as possible,” Ingersoll wrote, which is great for innovation in Kubernetes but can be bad for your particular deployment of it.

Kubernetes’ current release structure is such that “if you deployed a Kubernetes 1.6 cluster soon after it came out last March, you were expected to upgrade to 1.7 within roughly nine months or by the time 1.9 shipped in mid-December,” according to the post. This probably won’t faze too many of the Kubernetes cool kids (though another CNCF survey shows a significant percentage of Kubernetes deployments as running unsupported versions), but it will give serious pause to enterprises that have grown up on 10-year support policies, even in open source land (e.g., Red Hat Enterprise Linux).

SEE: Why containers are critical to successful DevOps projects (Tech Pro Research)

Again, you could take this on, but why? As Ingersoll pointed out, “Kubernetes platform providers are magically handling the migration around backwards-incompatible or forced migrations within upstream Kubernetes APIs.”

Even better, he said, “The Kubernetes-as-a-Service offerings, particularly Google Cloud’s Kubernetes Engine (GKE), are the well-polished bellwethers of what is currently the most stable and production-worthy version of Kubernetes.” Google created Kubernetes in the first place, and knows best how to keep it humming (so that you don’t have to).

It’s not alone. In a conversation with Red Hat executive Ashesh Badani, who runs the company’s OpenShift business, Badani told me that”Kubernetes is a great foundation for an application platform, but it’s still undifferentiated heavy lifting for most companies to integrate storage, networking, security, application frameworks, etc….as well as to keep them updated on a quarterly basis.” Red Hat delivers the power of Kubernetes in OpenShift; Google does it through GKE; Amazon manages it with EKS. Why would you go through the bother?

Kubernetes is hard enough without adding to its complexity with operational overhead. Yes, there’s a threat of lock-in to a cloud service, but given the availability of the open source Kubernetes the most potent risk of lock-in stems from never wanting to manage Kubernetes on your own once you’ve had a taste of GKE or OpenShift or another cloud option.