This article is based on reporting originally published on Forbes.com in December 2019, authored by Janakiram MSV.
The Long Road to True Hybrid Cloud
Ever since public cloud platforms became mainstream, the industry has chased one goal: genuine parity between on-premises infrastructure and cloud infrastructure. The ability to develop an application in a private data center and run it at scale on a public cloud — with no rework — has been the holy grail of enterprise architecture.
Early open-source projects took a serious run at this problem. OpenStack, CloudStack, and Eucalyptus all aimed to become universal hybrid cloud platforms, offering enterprises a way to extend private infrastructure outward to public providers. Despite significant investment from vendors and operators, workload portability remained elusive. The core issue was the hypervisor gap: the virtual machine managers (VMMs) running in on-premises data centers — VMware ESXi, Microsoft Hyper-V, and KVM variants — were fundamentally different from what powered AWS, Google Cloud, and Azure under the hood. Moving a workload between environments meant re-imaging, reconfiguring, or re-testing. Cloud bursting, the ability to seamlessly overflow on-premises workloads into the public cloud during peak demand, stayed largely theoretical.
Two Trends That Changed Everything: Containers and Kubernetes
Starting around 2015, two related but distinct technologies began reshaping this landscape: Linux containers and Kubernetes.
Containers as the Common Runtime
The container runtime became the lowest common denominator for running workloads across physical machines, private clouds, and public clouds. A container image bundles the application binary, its dependencies, and its runtime configuration into a single, portable artifact. Once built, a containerized application can run on any host that supports the container runtime — whether that host is a developer’s MacBook, a bare-metal server in a colocation facility, an Amazon EC2 instance, a Google Compute Engine VM, or an Azure Virtual Machine — with no changes to the application code or configuration.
In this sense, Docker and compatible container runtimes became a practical alternative to hypervisors for application portability. Where hypervisors virtualize hardware, containers virtualize the operating system environment, delivering a lighter and more consistent execution unit for modern software.
Kubernetes as the Universal Orchestration Layer
If containers replaced the hypervisor as the deployment unit, Kubernetes replaced the proprietary virtual machine manager as the orchestration and lifecycle management layer. Kubernetes provides a declarative API for scheduling containers, managing networking, handling storage, enforcing policies, and recovering from failures — consistently, regardless of the underlying infrastructure.
The industry converged on this combination quickly. With containers as the packaging format and Kubernetes as the orchestration engine, infrastructure teams finally had a standard infrastructure layer that worked across environments without vendor lock-in at the runtime level.
The Role of the CNCF in Ensuring Interoperability
Kubernetes being open source was necessary but not sufficient. An ecosystem of incompatible forks would have reproduced the same fragmentation problem that plagued earlier hybrid cloud efforts. The Cloud Native Computing Foundation (CNCF) — the governance body that oversees the Kubernetes project — addressed this directly through the Certified Kubernetes Conformance Program.
The conformance program requires every vendor distribution of Kubernetes to support the required upstream APIs. This means that a workload running on Red Hat OpenShift, VMware Tanzu, Rancher, or a managed service like Amazon EKS, Google GKE, or Azure AKS can be expected to behave consistently at the API level. For enterprises, this translates directly to freedom of choice: they can move between vendors or run across multiple vendors without rewriting application manifests.
The CNCF also governs containerd, the container runtime standard. As long as a container runtime adheres to the containerd specification (and the broader OCI standards), Kubernetes can schedule and manage those workloads. Together, containerd and Kubernetes form the foundation of what the industry now calls the cloud-native stack.
Vendor Adoption: Everyone Went All-In on Kubernetes
The combination of standardization and broad conformance drove rapid adoption across every tier of the market. Platform vendors including Red Hat, VMware, Canonical, Mirantis, and Rancher built commercial Kubernetes distributions capable of running in both enterprise data centers and major public clouds. Hyperscale cloud providers — Alibaba Cloud, AWS, Google Cloud, IBM Cloud, Huawei Cloud, Microsoft Azure, and Oracle Cloud — all launched managed Kubernetes services to meet enterprise demand.
Perhaps more significant was the emergence of Kubernetes-native hybrid cloud control planes — platforms that can manage Kubernetes clusters regardless of where those clusters run:
- IBM Cloud Paks (formerly IBM Cloud Private) — IBM’s hybrid cloud platform built on top of Red Hat OpenShift and Kubernetes.
- Google Anthos — announced at Google Cloud NEXT 2019, Anthos allows organizations to deploy and manage applications across on-premises environments, Google Cloud, and other public clouds from a single control plane.
- VMware Project Pacific and Tanzu Mission Control — announced at VMworld 2019, these offerings integrate Kubernetes natively into vSphere, allowing vSphere administrators to manage containerized workloads alongside traditional VMs from familiar tooling.
- Microsoft Azure Arc — extends Azure management capabilities to Kubernetes clusters running outside of Azure, including on-premises and on competing public clouds, alongside Azure Kubernetes Service (AKS).
What these platforms share is that Kubernetes sits at the center of their hybrid strategy. Rather than abstracting Kubernetes away, they expose and extend it. Workload portability and cross-environment scaling are delivered by leveraging the same Kubernetes primitives — Deployments, Services, ConfigMaps, RBAC policies — across every target environment.
Why This Matters for DevOps Teams
For platform and DevOps engineers, the practical implication of this shift is significant:
- Consistent developer experience: A developer writing a Kubernetes manifest on a local cluster (using tools like kind or minikube) can deploy that same manifest to a production cluster in any conformant environment. The API contract holds.
- Portable CI/CD pipelines: Build pipelines that produce container images and apply Kubernetes manifests are inherently portable across cloud providers. There is no proprietary deployment agent to swap out.
- Unified policy and observability: Platforms like Anthos and Azure Arc allow teams to apply consistent RBAC policies, network policies, and monitoring configurations across clusters running in different environments from a single pane of glass.
- Reduced vendor lock-in risk: The CNCF conformance program provides a contractual API baseline that limits the risk of being stranded on a proprietary runtime.
Kubernetes as the Universal Control Plane
The trajectory of Kubernetes points toward an even broader role than container orchestration. Projects within the cloud-native ecosystem are extending Kubernetes to manage virtual machines (KubeVirt), serverless workloads (Knative), bare-metal provisioning, and legacy stateful applications. The Kubernetes API — with its extensible Custom Resource Definitions (CRDs) and operator pattern — is increasingly used as a universal control plane that can manage almost any infrastructure resource declaratively.
What OpenStack attempted to achieve through a purpose-built API surface, Kubernetes is achieving organically through ecosystem extension. The original promise of hybrid cloud — write once, run anywhere, manage consistently — is no longer aspirational. For organizations that have standardized on Kubernetes, it is operational reality.
Key Takeaways
- Early hybrid cloud platforms (OpenStack, CloudStack, Eucalyptus) failed to deliver workload portability because hypervisor heterogeneity was too deep to abstract.
- Containers solved portability at the application runtime level; Kubernetes solved it at the orchestration and lifecycle management level.
- The CNCF Certified Kubernetes Conformance Program ensures API consistency across all major distributions and managed services, enabling genuine vendor interoperability.
- Major infrastructure vendors (IBM, Google, VMware, Microsoft) have all launched Kubernetes-native hybrid cloud control planes that manage clusters across on-premises and multi-cloud environments.
- Kubernetes is evolving beyond containers toward a universal, extensible control plane for all infrastructure types.