A New Breed of Kubernetes Services
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 an old friend of InfluxData, David McKay, who challenged the notion that anything that you get from Kubernetes is “free.” I thought that he was a bit kind in his video; I was expecting him to extend the Florida metaphor (that Florida provides a lot benefits to residents, but it takes a lot of effort to move there) to include the powerful tropical storms that expose weakness in your infrastructure that you were wholly unaware of, causing significant downtime and rebuilding effort.
To be clear, I appreciate Kubernetes; and at InfluxData, we are able to leverage it in powerful ways. We are able to use it to deliver our stateful application — InfluxDB 2.0 is a database at its core, after all. We are able to target multiple clouds and multiple regions in those clouds, and we have achieved significant velocity and enviable stability.
However, as David points out, this was not free. At InfluxData, we do not consider ourselves a Kubernetes tooling vendor, although many customers use us to monitor their Kubernetes clusters and interesting monitoring applications are built on top of us. But since we have no particular interest in maintaining bespoke Kubernetes tooling, we strongly prefer a “buy over build” approach. We try to choose tools that are supported by vendors, or that are well-supported in open source and to which we can contribute our efforts upstream.
For example, we are heavy users of Argo CD. Argo made it possible for us to implement continuous delivery. This required us to host Argo in our infrastructure, and we wrote some modest amounts of bespoke code to embed Argo in our processes. Argo is one example of early Kubernetes-enabling software that we appreciate, because it made our use of Kubernetes possible, but not necessarily easy.
Considering how much you hear from big companies that Kubernetes is too hard, you would think that an engineering team in our position would be well-served, since so many big companies are clamoring to solve our problems. However, when I look at the tooling that we actually adopt, they tend to be smaller projects by smaller teams, and in many cases, require copious amounts of code for us to integrate. Of course, the cloud service providers make a nice revenue stream from us running clusters in their clouds. But otherwise, why is Kubernetes still so hard?
One reason is that while these people working at these large companies — even people who were the progenitors of Kubernetes, in some cases — recognize the difficulties of running 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 have incentives to make it easier to run Kubernetes in general, or to focus on making Kubernetes easy on the platforms that generate revenue for them.
The Cloud Native Computing Foundation (CNCF) has similarly not seemed too interested in making Kubernetes easier. The CNCF seems overly focused on adding more tools to its landscape, but choosing, adopting and using from a grab bag of tools requires a huge amount of effort and code. We did try engaging with the CNCF user groups to join other practitioners to discuss how to solve problems together, but the CNCF meetings we attended were mostly focused on the bureaucracy of running the meetings or inducting tools into the CNCF landscape rather than working together to make Kubernetes easier. Important topics, but not particularly helpful for reducing our operational burden or improving our effectiveness as practitioners.
I have seen 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, for practitioners.
These smaller companies provide services, instead of tools, that reduce the effort needed to operate a cluster and solve real business problems.
I am familiar with Nobl9 because it is a InfluxData customer. It provides a service-level objective platform to define reliability goals. Send your Kubernetes, or other, metrics, and it will provide an SLO dashboard and error budget alerts for you, automatically. This solves a real pain point, but in a way that does not add to your burden of maintaining your Kubernetes cluster. It also doesn’t care where you run your cluster, or what other tooling you use.
Similarly, Replicated, not an InfluxData customer, provides tools and services that allow you to take your 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 and without the need to write significant amounts of new deployment code or even maintain new services. It even solves the problem of delivering to customers who are not yet running K8s, by providing a well-supported installer that can be easily targeted and run wherever the customer is.
While Tackle.io (we are a customer) is not Kubernetes-specific, it solves the thorny problem of multi-cloud service provider (CSP) marketplace integration. When your Kubernetes-based SaaS service goes live, you will soon find that customers want to purchase your service through the different cloud marketplaces. The individual CSPs don’t particularly invest in making it easy to target multiple marketplaces. Because Tackle.io is not embedded in such a company, it is 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:
- Their revenue comes directly from providing value to Kubernetes practitioners, not from enabling the use of infrastructure or other services.
- The companies are started by practitioners and directed at solving pain points that those founders experienced in real life.
- They provide services, not software. They reduce operational burden rather than add to it.
- They seem much more concerned about providing value to their customers than being included 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.
