We’ve all seen the recent spate of articles and quotes from different Kubernetes luminaries that point out that Kubernetes is hard to use. I particularly enjoyed this video from David McKay where he summed up these articles with a challenge to the notion that anything that you get from Kubernetes is “free.” 

I actually thought that he was a bit kind in his video; I was expecting him to extend the Florida metaphor to include the powerful tropical storms that come and expose weakness in your infrastructure that you were wholly unaware of, causing significant downtime and rebuilding effort.

To be clear, I appreciate Kubernetes, and many companies are able to leverage it in powerful ways. For example, it can be used to deliver stateful applications and enable the use of multiple clouds. 

However, as David points out, this is not free. Some companies have no particular interest in maintaining bespoke Kubernetes tooling and prefer a “buy over build” approach by choosing tools that are supported by vendors or that are well supported in open source, and which can contribute to efforts upstream.

Kubernetes is early. It may still be hard to use but its existence enables software development more than its complexity hinders it. 

(Mis)Alignment of interests
Considering how much you hear from these big companies that “Kubernetes is too hard,” you would think that an engineering team’s position would be well-served, since so many big companies are clamoring to solve our problems. However, when you look at the tooling that is actually adopted, it tends to be smaller projects by smaller teams, and in many cases, requires copious amounts of code to integrate. Of course, the cloud service providers make a nice revenue stream from companies running clusters in their clouds, but otherwise, why is Kubernetes still so hard?

One reason for this is that while people working at these large companies recognize the difficulties running Kubernetes, even those who were progenitors of Kubernetes, they are not operating Kubernetes at scale. So, the Kubernetes tooling that comes out of these companies is like wine from a vintner who does not drink wine. It may be manufactured correctly, but the feedback loop to ensure that the tooling fits into the real world and solves real problems is not there.

Additionally, and this is just speculation, I notice that most of these companies are affiliated with cloud service providers or offer expensive “enterprise” solutions. I am skeptical that such companies are incented to make it easier to run Kubernetes in general, and are incented to focus on making Kubernetes easy on the platforms that generate revenue for them.

The CNCF has similarly not seemed too interested in making Kubernetes easier. The CNCF seems focused on adding more tools to their “landscape,” but choosing, adopting, and using from a huge grab bag of tools requires a huge amount of effort and code. 

Hope in the next generation
There are recent signs of hope that Kubernetes will become easier to use, but those signs come from a new wave of smaller startups that are started by practitioners and for practitioners. These companies provide services, instead of tools, that reduce the effort needed to operate a cluster and solve real business problems.

Nobl9 provides a service-level objective (SLO) platform that defines reliability goals. Users can send their Kubernetes (or other) metrics and Nobl9 provides an SLO dashboard and error budget alerts, automatically. This solves a real pain point but in a way that does not add to the burden of maintaining Kubernetes clusters. They also don’t care where clusters are or what other tooling is used.

Similarly, Replicated provides tools and services that allow companies to take their existing SaaS service and package and deliver updates to enterprise customers, easing the opening of new revenue streams for Kubernetes users. This allows you to extend your current Continuous Delivery pipeline to meet the needs of “on-prem” customers, no matter where those customers are operating, without the need to write significant amounts of new deployment code or even maintain new services. They even solve the problem of delivering to customers who are not yet running Kubernetes by providing a well-supported installer that can be easily targeted, and run wherever the customer is. 

While Tackle is not Kubernetes specific, it solves the thorny problem of multi-CSP marketplace integration. When a Kubernetes-based SaaS goes live, companies will soon find that customers want to purchase its service through the different cloud marketplaces. The individual CSPs don’t particularly invest in making it easy to target multiple marketplaces. Because Tackle is not embedded in such a company, they are positioned to provide services that allow you to reach more customers without imposing a significant operational or even development burden.

These companies have a few things in common:

  1. Their revenue comes directly from providing value to Kubernetes practitioners, not from enabling the use of infrastructure or other services they charge for.
  2. The companies are started by practitioners and directed at solving pain points that those founders experienced in real life. 
  3. They provide services, not software. They reduce operational burden rather than add to it.
  4. They seem much more concerned about providing value to their customers than they are in various CNCF processes.

I am hopeful that over the next year, such companies will succeed, and make it possible to opt into a web of CSP-neutral services that, in turn, allow practitioners like us to accelerate providing value to their own customers while realizing the real benefits of Kubernetes, such as cloud neutrality, and high feature velocity.

To learn more about the transformative nature of cloud native applications and open source software, join us at KubeCon + CloudNativeCon Europe 2021 – Virtual, a virtual event hosted by the Cloud Native Computing Foundation, which takes place from May 4-7.