It’s hard to turn around these days without bumping into a Kubernetes distribution. For example, Mirantis recently buffed its OpenStack distribution to use Kubernetes as an internal component and for container management. Major Linux server distributions include it now.
For Kubernetes adopters, it’s all good news. It means the most remarkable development in the container world since, well, containers themselves is enjoying strong uptake and acceptance.
But rapid proliferation can also be a warning sign. The excitement for OpenStack’s open approach to cloud infrastructure cooled once people realized its inherent complexity and clunkiness, and some vendors lost their shirts trying to build OpenStack businesses.
Does that mean attempts to commercialize Kubernetes will also run aground? It’s less likely, given that Kubernetes already enjoys solid success, but that doesn’t mean it can’t happen. Here’s how existing and future commercial ventures could avoid going pop.
1. Kubernetes plus something else is a safe bet
Most Kubernetes “distributions” aren’t Kubernetes alone. They’re offerings like Linux distributions that have Kubernetes as a standard-issue component. Case in point: Canonical’s Ubuntu, which has a Kubernetes distribution and an installer to go with it that can target both local metal and remote clouds.
It’s easy to give people exposure to a new technology by making it part of something they’re already comfortable with. If Kubernetes is a standard-issue component of a Linux distribution (Ubuntu), cloud kit (OpenStack), or infrastructure management system (DC/OS) they already work with, they have incentive to try it.
The fact that Kubernetes is casually available through such channels is a big sign it’s welcome and it’s a good value-add.
2. Keep the complexities separate
People might shy away from the complexities of a Kubernetes offering, but that’s not necessarily due to Kubernetes.
The average Kubernetes install can become complicated when you’re setting up all its prerequisites, like configuring system services or setting up TLS correctly. People new to Kubernetes have to grapple with the concepts, abstractions, and terminology it uses (pods, for example), but that’s customary for most any new technology.
Kubernetes’ maintainers are trying to make the setup process less onerous. Kubernetes 1.4, for instance, provided some improvements, but most of the difficulty isn’t exclusive to Kubernetes, and that should always be communicated clearly.
3. Standalone distributions need to offer more than convenience
Most existing Kubernetes distribution methods are package deals for the convenience of having it bundled with familiar technology. But there’s room for standalone distributions that offer the convenience without the commitment.
That’s the premise for Heptio, a startup founded by former Googlers and Kubernetes co-creators Craig McLuckie and Joe Beda. Their plan is to provide standalone Kubernetes distributions for enterprises that aren’t wrapped into an existing product—a Linux distribution, for instance.
Right now, not much of Heptio’s vision is available for direct inspection. Aside from offering consulting services and training, Heptio is behind an AWS Quick Start to deploy a Kubernetes cluster on AWS. It’s a good idea in the abstract, since Kubernetes isn’t natively supported on AWS, but it hardly requires the backing of a whole startup.
Based on what few tea leaves Heptio has offered, the long-term vision of McLuckie and his compatriots is to allow VM-centric enterprises to take up cloud-native technologies like Kubernetes painlessly and profitably. It sounds great in the abstract, but abstractions don’t turn heads. Others have tried and failed to communicate to enterprises how cloud-native architectures offer lots more than a new place to put legacy apps.
Thus, it’s urgent for anyone planning to offer Kubernetes in a commercial form where it’s the main draw to send the right messages about what it can do. Though great, Kubernetes won’t sell itself.