Trying to keep from sinking under the squirming, sprawling, overstuffed stack of cloud-native computing projects
when relevant content is
added and updated.
when relevant content is
added and updated.
Cloud image via FreeImages
By James Kobielus (@jameskobielus)
If you’re having trouble keeping the cloud-native computing stack in clear focus, you’re not alone. Of course, you should be following what emerges from the working groups of the Cloud Native Computing Foundation (CNCF), which is the principal community defining the growing open-source stack for containerized computing environments.
When following CNCF, the shortcut has been to focus on the development of Kubernetes, which was the first project to achieve “graduated” status and, of course, near-universal adoption among cloud service and solution providers. Kubernetes is far and away the most widely adopted CNCF project, being implemented currently in 34 certified vendor distributions and 21 hosted platforms that are commercially available. As detailed here, Kubernetes has been implemented by vendors of all the leading infrastructure-as-a-service, container, and Linux platforms. Among managed cloud solution providers, Alibaba Cloud, AWS, Cisco. Microsoft, Google, IBM. Oracle, Red Hat, and VMware all have their respective Kubernetes engines.
At first glance, it may seem like Kubernetes alone is a complete ecosystem for cloud-native computing. It is the core of cloud-native microservices that are platform agnostic, dynamically managed, loosely coupled, distributed, isolated, efficient, and scalable.
Kubernetes continues to mature as it leverages containers, orchestrations, service meshes, immutable infrastructure, and declarative APIs. It provides an exceptionally rich API that abstracts an evolving, sprawling, and complex set of concepts, tools, extensions, add-ons, proxies, objects, orchestration/packaging charts, storage, policies, statefulness, and configuration, networking, and administration settings. And it supports deployment over a wide range of cloud-native platforms at the nodes, cluster, and federation levels, enabling execution of containerized microservice workloads on diverse public cloud, on-premises, and bare metal environments.
But Kubernetes is not the sum total of cloud-native computing, and one would be naïve to consider it, even in its unforked kernel, as providing any assurance of multi-platform, multi-vendor interoperability.
For starters, Kubernetes’ huge range of implementation and management options makes it difficult to set up and configure. This excessive complexity places a significant burden on IT solution vendors and enterprise tech administrators, who have the unenviable task of having to sift through myriad details and make it all work together seamlessly.
Exacerbating the complexities is the fact is the huge range of CNCF-certified Kubernetes distributions and hosted PaaS services on the market. On many if not most of these, vendors have patched and extended the Kubernetes kernel and integrated it with various Linux OS and container management platforms in order to stand up useful cloud-native capabilities in production settings.
But Kubernetes is just one component of a much larger, more complex cloud-native stack in the making. There many other cloud-native open-source projects (either “incubating” or “sandbox”) under CNCF’s purview that need to come to fruition before the Kubernetes-hubbed stack can be considered feature-complete, production-ready, or fully mature.
So far, the only other CNCF project has achieved graduated status so far is Prometheus, an open-source environment for monitoring Kubernetes clusters and containerized microservices. Projects still incubating at CNCF include Helm (package management), Fluentd (logging), gRPC (remote procedure call), Containerd and Rkt (container runtime), CNI (networking), Envoy and Linkerd (service mesh), OpenTracing and Jaeger (distributed tracing), Notary (security), TUF (software update), Vitess and Rook (storage), CoreDNS (service discovery), and NATS (messaging).
With respect to Kubernetes or any other project in the CNCF stack, even when it has attained “graduated” status, the current kernel of that project may not support the degree of interoperability, reliability, security, performance, scalability, and other attributes required in every cloud-native computing scenario. Under such circumstances, it may be necessary for vendors and/or users to “fork”—in other words, extend, supplement, or otherwise modify the open-source code–in order to stand up production-grade cloud-native computing deployments. Under those circumstances, CNCF must double down its efforts to evolve the kernels of the impacted projects in order to eliminate the need for the forked distributions. In so doing, CNCF would be advancing its core objective of ensuring platform-agnostic cloud-native interoperability up and down the stack throughout the industry.
Still, it would be shortsighted to imagine that CNCF is the sole industry forum for promoting multiplatform cloud-native interoperability. If what you’re containerizing and orchestrating are data-centric applications, you’ll need to pay attention to the diverse industry initiatives to rearchitect various enterprise DBMS, Hadoop, Spark, machine learning DevOps, TensorFlow DevOps, inferencing, stream computing, object storage, block storage, and multi-cloud storage platforms around Kubernetes and its sibling projects All of this industry activity is happening outside CNCF’s purview, but it’s just as important to the dream of a completely cloud-native application stack.
Yet another complicating factor for cloud-native professionals is the wide range of open-source projects that may take root in vendor solutions and enterprise deployments without becoming official CNCF projects. In particular, I’m thinking of Istio (microservice connection, security, and control mesh), Kubeflow (for DevOps workflows on containerized machine learning apps), Virtual Kubelet (for event-driven, stateless, serverless access to orchestrated, containerized microservices), and KubeVirt (building, modifying, and deploying applications residing in both containers and virtual machines in a shared environment). You won’t find any of these called out by CNCF as being projects under active development in its working groups.
If your head isn’t spinning in trying to understand where this new cloud-native ecosystem is headed, you’re just not paying attention.