This week, the annual KubeCon + CloudNativeCon North America 2018 event taking place in Seattle will give the cloud computing industry a chance to take stock of how far Kubernetes has come.

On the flip side, the show also will work through the issues that may be preventing this open-source container orchestration platform from achieving its full potential.

Kubernetes has been a banner story in high tech throughout 2018, and the technology looks like it will continue its momentum toward ubiquitous adoption in coming years. The Kubernetes ecosystem has become amazingly vibrant, though that’s a double-edged sword.

Providers’ commercial adoption of Kubernetes has been the dominant story in cloud computing this year, thanks to making it easier for companies to deploy containers, the software that enables applications to be written once and deployed on many computer environments from on-premises data centers to public clouds. One clear indicator of Kubernetes’ maturation is the rich ecosystem of open-source projects that have grown up around it. These include projects for monitoring (Prometheus), service proxy (Envoy), remote procedure call (gRPC), container network interface (CNI), DNS-based service discovery (CoreDNS), packaging environment (Helm) and on and on.

Another sign of Kubernetes’ growing dominance is rapidly expanding enterprise adoption. The Cloud Native Computing Foundation’s recently released biannual enterprise user survey reports that use of cloud-native technologies in the enterprise has grown more than 200 percent since December 2017. Kubernetes is far and away the top choice for container management, with 83 percent saying they use it in private, public, hybrid or multicloud deployments. About 40 percent of enterprise respondents reported that they are now running Kubernetes in production.

Among cloud-computing vendors, Kubernetes is a key competitive focus. All of the leading public-cloud providers have made sizable investments in this open-source technology. Amazon Web Services Inc., Microsoft Corp., Google LLC, IBM Corp., Oracle Corp. and Alibaba Holding Co. Ltd. all have their respective Kubernetes engines, as do Red Hat Inc., Cisco Systems Inc., VMware Inc. and others.

Kubernetes ecosystem proliferation roils the market

However, enterprises that adopt Kubernetes now are treading in a minefield of evolving open-source projects that still don’t add up to a mature, vendor-agnostic stack that addresses a comprehensive range of production-grade enterprise application use cases for cloud computing.

How confusing is the Kubernetes ecosystem? The core Kubernetes open-source platform has become a bewildering field of dozens of vendor-tweaked distributions and hosted cloud implementations. Not only that, but the deepening stack of open-source projects that build on and supplement the Google-spawned Kubernetes is twice as confusing.

Many, but far from all, open-source containerization-related projects are under the purview of the Cloud Native Computing Foundation, with only a handful beyond Kubernetes. Most notably, there are Prometheus for monitoring and Envoy for proxying that have “graduated” into a semblance of standardization.

But breakaway successes among the disparate subprojects have yet to emerge. Consequently, enterprises that adopt Kubernetes-based solutions face the risk that they may need to engage in “rip and replace” migration exercises in a year or two when the market shakes out and we all learn which of today’s promising open-source projects have fallen off the industry’s radar.

The recent effort by Oracle to “curate” a core set of CNCF projects — graduated and otherwise — was laudable. But given how this is just one company, it didn’t do much to bring the cross-industry coherency that this stack badly needs if cloud-native computing hopes to mature into a backplane for orchestration of any-to-any containerized microservices. And it can’t begin to secure the growing attack surface that exposes itself across the vast universe of heterogeneous multivendor, federated and fragmented Kubernetes distributions, versions and tooling that proliferate across the multicloud.

Kubernetes’ maturing open-source core

Nevertheless, the Kubernetes open-source platform shows signs of maturing. According to recent source-code analysis by source{d}, the core Kubernetes codebase, currently in version 1.13, is stabilizing.

The total number of contributions to the core Kubernetes project has slowed down in 2018. Commit velocity is decelerating for the core Kubernetes projects. The core CNCF-managed Kubernetes codebase is stabilizing over time at about 1.75 million lines of code, while its public application programming interface endpoints are plateauing at about 16,000. Meanwhile, contributions to Kubernetes special interest groups and incubator projects within CNCF are also slowing down.

But that doesn’t mean that innovation in the Kubernetes ecosystem is slacking off. The source{d} research also shows that more innovation is coming from Kubernetes-related projects that are being managed outside CNCF in external GitHub organizations. Much of the recent activity in this larger Kubernetes ecosystem involves developing cluster federation, container runtimes, supporting scalable workload management for high performance computing and machine learning, and elastic load balancing.

On the commercialization front, it’s clear that vendors are not slowing down in building their cloud-computing environments on the core Kubernetes ecosystem projects. At the same time, many of the most active cloud-computing solution providers are also proliferating their own new open-source projects that address requirements outside the core scopes of the CNCF community projects.

For example, consider AWS’ recent announcement of Firecracker, a lightweight, open-source virtual machine monitor that uses the Linux Kernel-based Virtual Machine or KVM. Firecracker enables creation and management of secure multitenant containers and Lambda functions in serverless clouds. It enables popular container runtimes such as containerd to manage containers as microVMs. In this way, it allows developers to leverage virtual machines’ workload isolation while gaining the efficiency of containers running on Kubernetes backplanes.

Licensed under Apache v2.0 and downloadable from this GitHub repo, Firecracker is engineered to optimize the transient and stateless workloads characteristic of serverless environments. AWS Lambda uses Firecracker as the foundation for provisioning and running sandboxes upon which that public cloud provider executes customer code.

Firecracker provides a secure device model that reduces memory footprint and attack surface area while providing a high density of microVMs on each server. Its minimal device model enables faster startup times (less than 125 ms on an i3.metal with the default microVM size) while reducing the attack surface. It enables packing of thousands of microVMs onto a single machine. Users can access its in-process rate limiter to control, with fine granularity, how network and storage resources are shared, even across thousands of microVMs.

What Wikibon finds most noteworthy about Firecracker is the way in which AWS is bringing Kubernetes containerization into greater alignment with the serverless and virtualization paradigms. This has not been a dominant focus of the core CNCF Kubernetes projects, though it’s clearly a growing requirement among enterprises that have made investments in all of these technologies.

Can CNCF align Kubernetes with other communities?

Continued innovation outside the core Kubernetes community is absolute essential for the maturation of this ecosystem to advance. Recently, Google Fellow Eric Brewer acknowledged that the company he works for — which is still far and away the top Kubernetes community contributor — may have released the project to open source a little too early and left too many questions for the community to figure out.

However, Brewer’s statement doesn’t address the root issue. It would have been better if Google had already engaged community while it was still developing and proving out the core Kubernetes-based stack prior to open source. There is a case to be made for having a visionary vendor flesh out a coherent — albeit complex — solution stack prior to releasing it all to the open-source community.

Showing perhaps that Google has learned this lesson, it is moving with all deliberate speed to build out another core open-source stack, TensorFlow, with a robust set of functional layers, tools and interfaces, and — just as important — wide-ranging community engagement.

At some point, Google may — and probably should — submit the open-source TensorFlow stack to a CNCF-equivalent industry group to formalize the development and governance of that stack, and to align it with the Kubernetes ecosystem. In two to three years’ time, the Kubernetes and TensorFlow ecosystems will have converged, as the containerization of AI DevOps pipelines accelerates and still-embryonic open-source projects that address those requirements — most notably, Kubeflow — become central to all AI app development in the cloud-besotted world where Kubernetes is ubiquitous.

Should Google submit TensorFlow to CNCF? It’s not clear at this point whether CNCF, in its current form, can bring the coherency needed to keep that open-source stack from straying from its core use cases while also ensuring that its working groups have the right touch points into the Kubernetes working groups to ensure necessary alignments going forward.

To see what the Kubernetes market has to say about its ongoing evolution, check out theCUBE this week from KubeCon, starting today. All of theCUBE’s exclusive interviews from KubeCon + CloudNativeCon North America 2018 will be available on theCUBE’s dedicated website, the dedicated Ustream channel and SiliconANGLE’s dedicated YouTube channel.

Image: Vladimir Vivien/Twitter