The future of the Kubernetes ecosystem isn't all about cloud

Kubernetes emerged to fit a need

Kubernetes was originally a Google project, built to manage a search-and-services ecosystem that's very different from how enterprises run their core business applications. Kubernetes -- or Borg, as the internal Google tool was known -- had to be flexible and had to provide a lot of hooks and options.

The open source version is still focused largely on filling a gap in the market -- app support for public cloud, cloud-native and microservice-centric workloads. The Kubernetes ecosystem builds on that, adding features like service mesh technology and multi-cloud capabilities.

Lingering issues to address

Some of the biggest barriers to adoption are the complexity and skills required to install and use Kubernetes. Those already committed to Kubernetes note that the technology has become more complicated over time, particularly the corresponding ecosystem -- the fusion of middleware tools needed to fully manage cloud-native application lifecycles.

The other problem is the ecosystem itself. Most enterprises accept it as the roadmap to a cloud-native journey, but not all are certain they want to go there. And almost all of them believe many -- if not most -- of their applications won't make the trip. Users want a version of Kubernetes designed to work not only in cloud-native deployments, but in their data center, as well as across hybrid and multi-cloud environments. Business applications of the future don't just live in the public cloud, they live everywhere.

Kubernetes is succeeding because it's the centerpiece in an application model, but no such model can survive if it's too complex for the average developer or operations professional. It has to support the core business applications that are the basis for all enterprise IT, and the Kubernetes community needs to address both these issues to take the next step towards IT dominance.

The common thread in solving these two problems is, ironically, expansion of the Kubernetes ecosystem itself. It needs to be a container ecosystem, not just a cloud-native ecosystem. When Kubernetes came along, it was an extension to Docker that made it easier to work with microservice-centric applications. Going forward, it needs to address a broader set of needs, such as handling monolithic applications, or bridging the gap between public clouds and private data centers.

The next fight: public cloud vs. on premises

Kubernetes today is still focused largely on public-cloud deployments. Cloud providers want their Kubernetes services to be sticky. Their goal is to provide a package that simplifies application deployment and redeployment in the cloud but also binds customers to their platforms. The race for cloud-Kubernetes dominance has left the data center behind, and insulated Kubernetes evolution from the complexity problem by burying it in a managed service.

The data center software giants obviously see this as a threat to their own businesses. They now recognize they can turn the Kubernetes market -- and the whole cloud movement -- in their favor by exploiting the complexity and hybrid cloud issues. Foremost among these vendors are VMware and IBM-Red Hat, which realize multi-cloud is their path to Kubernetes leadership.

VMware has a deal with Amazon to host vSphere in the cloud, and it's begun to build relationships with other cloud vendors, including Microsoft and Google. It also has its own managed Kubernetes service. Red Hat and IBM have always been strong in the data center, and IBM, post-Red Hat acquisition, is now working hard to harmonize its own container approach -- Kabanero -- with OpenShift, which relies on Kubernetes and can run on premises or in the public cloud.

The data-center-centric Kubernetes model creates a layer of abstraction, a representation of hosting that envelops any public cloud or on-premises environment. They're no longer trying to distinguish private clouds from public clouds; they're all just places to host containers. The application is what matters, and that's what's going to transform Kubernetes.

Make a true hybrid cloud a reality

Most hybrid cloud architectures today separate applications into a public cloud front end and a data center core, but Kubernetes and its ecosystem could change that. For example, a container-based application that could cross the boundary between public cloud and data center could enable an IT team to have one set of hosting resources supplement or back up another.

Abstraction will be critical to manage distributed Kubernetes clusters across environments. It unifies and simplifies operations and produces an operator interface that hides all the technical details of Kubernetes. This model solves both of Kubernetes' problems.

Microsoft already has Azure Service Fabric, a kind of universal service bus, and it's also been a proponent of interweaving it with other popular service mesh technologies. Service mesh connectivity to the data center would address the hybrid cloud application integration requirements, even if the data center wasn't fully transitioned to microservices.

Kubernetes ecosystems built by data center software providers are already forcing public cloud providers to adjust. Look no further than Google Anthos, which comes from the very company that created Kubernetes. A simpler, broader-based Kubernetes ecosystem is on the way, and that's the ecosystem that will carry Kubernetes and containers into the future.