Cisco CTO to Cloud-Native Group: Stop Building Walls

In very brief comments delivered Tuesday morning in Seattle, at a conference of developers and other members of the Cloud Native Computing Foundation, Cisco CTO Ken Owens candidly advised attendees — including several Google engineers — that the way forward for building their Kubernetes orchestration platform is not to create divisions between themselves, the rest of the contributor community, and the vendor-driven platforms with which they’ll have to integrate.

“Don’t build walls.  Don’t build this environment where you have [this],” said Owens, indicating a slide showing a “meme”-style picture of U.S. Republican presidential candidate Donald Trump, inside a caption that read, “We need to build a wall | VMware is going to pay for it.”

“The CNCF is building more and more of an ecosystem around helping you in this journey,” Owens continued, referencing Cisco’s involvement in the Foundation.  “So leverage us, work with us, and we’ll help you get there.”

Equalization Without Equivocation

Software-defined infrastructure is a world with a handful of continents, all of which appear to be traveling in different directions.  CNCF represents the emerging ideal of Kubernetes: that application-centered workloads, rather than entire virtual machines, may be staged and managed in an environment where the details of the underlying hardware and platform minutiae are abstracted from it.

It’s one way for hyperconvergence to finally make inroads, and for vendors of hyperscale hardware to spread out their customer base, between mid-level enterprises looking to deploy hybrid clouds, and corporations that need workload portability across continents.  Live migration of virtual machines makes something called “portability” feasible today, but distributing pieces of workloads (minus the overhead of VM operating systems and libraries) across cloud platforms, on-premises and in public spaces, requires a more effective orchestrator.

To this end, Kubernetes (with Google’s backing) is competing against Apache Mesos in the open source space.

“The first thing you have to do, when you’re making this move toward Kubernetes and cloud-native architectures,” said Cisco’s Owens today, “is you have to know where you’re going.  You have to have a vision, and have a set direction that you want to get to, and think about how you’re going to get there.  Don’t just start — Everyone just starts doing proofs-of-concept, and plays around with the technology.  That’s all good things to do, but at some point you have to know where you’re going to head with this new technology, and what you want to do as your organization grows.”

Whose Level Playing Field Is It?

Taken out of context and read as a paragraph by itself, Owens’ statement may seem a little generic.  But here, in this particular venue, there’s a point to his statement that could very easily be missed.

The CNCF is a Linux Foundation project that came together in 2015 with the objective of assembling a platform around containerized workloads — the kind made popular that year by the rapid rise of Docker.  Google rapidly took the lead with the CNCF group, contributing code based on an orchestration concept it originally built in-house, called “Borg.”  The CNCF’s founding came literally on the heels of the creation of the Open Container Initiative, launched after Docker Inc. donated a critical piece of containerization technology — the container runtime — to the open source community.

At first, there was confusion and even some dispute over why the OCI and CNCF were founded separately.  Didn’t both foundations seek to advance the cause of containerization?

But since the start of this year, OCI’s mission started centering around standardizing the container format, which ended up helping wean containers from their tight association with Docker.  CNCF, meanwhile, focused on the orchestration of workloads, which include Docker and CoreOS rkt containers, but which have the theoretical possibility of expanding in scope.  For example, a China-based firm called Hyper has constructed a way for Kubernetes to orchestrate hypervisor-driven workloads, and to pair containers with a new kind of hypervisor.

This while VMware (which we can assume will refuse to pay for any wall) “embraces and extends” the containerization concept, taking after Microsoft.  It’s built two container platforms of its own — one which pairs containerized workloads with VMware ESX hypervisors in a hybrid environment with vSphere, and another which would replace vSphere with a fully containerized system built on its NSX network virtualization platform.

In both of those environments, however, it may be possible to run Kubernetes.  And if you’re asking why, consider that vSphere’s management environment may not have the flexibility to control microservices in a manner that makes them scalable.  Theoretically, VMware’s platform can be set to manage lower-level infrastructure, while Kubernetes devotes itself purely to making microservices work on the upper tier of a cloud-native architecture.

Point of Reference

On Tuesday, CNCF Executive Director Dan Kohn gave attendees their first peek at what that architecture would look like, at least on paper.  In version 0.9 of what it calls Cloud Native Reference Architecture (not to be confused with the IBM project with the same name) various open source components including Docker and Kubernetes are distributed among tiers in a five-ply stack: from top to bottom, Application Definition / Development, Orchestration and Management, Runtime, Provisioning, and Infrastructure.  Arguably, Kubernetes would have a place in the second layer from the top, and Docker and CoreOS rkt (pronounced “rocket”) one layer below.

“In the era of GitHub, people do not need to be told what to do, they need help, services and common infrastructure that we can provide,” wrote CNCF Technical Committee Chairman Alexis Richardson (also the CEO of SDN software maker Weave), in a CNCF blog post published Tuesday.  “We ask them how we can help — we don’t tell them, we don’t make them join committees.  We love open source, which is fast, more than open standards, which are important but emerge slowly over time.  We are not a kingmaker organization — we believe the market and community will select leaders (plural) in time.”

It’s another way of saying, don’t build walls.  The problem is, with five tiers in the emerging CNCF reference architecture, there are at least four opportunities for some very tall walls — or some nice fences.