VMware CEO: A Virtual Machine Is Still the Best Place to Run Kubernetes

It was not vSphere which took center stage during Monday morning’s keynote session at VMware’s VMworld 2018 conference in Las Vegas. While it’s clear the virtual machine environment and its supporting ecosystem won’t just disappear (no such widely deployed platform ever has), Monday resolutely answered the question of which principal strategy VMware intends to pursue, to lead its enterprise customers into the new realm of workload management ­­— the realm upon which stacks, new and old, have been known to be built.

“Literally, the world has become this complex network,” remarked CEO Pat Gelsinger. “We have seen the world go from [being] defined by rigid boundaries… Simply put, in a distributed world, hardware cannot possibly work. We’re empowering customers to secure the applications and the data regardless of where they sit. We think of the virtual cloud network as these three fundamental things: a cloud-centric networking fabric, with intrinsic security, and all of it delivered in software. The world is moving from data centers to centers of data.”

Home Space

Rather than perceiving VMware’s customers as sharing an environment, VMware now characterizes its user base as sharing an infrastructure platform: NSX, the virtual networking layer that spans multiple physical address spaces across data centers and clouds with a single namespace. An enterprise could deploy workloads in any variety of manners, perhaps simultaneously. Yet as long as their namespace and address distribution rely on NSX as an underlying platform, VMware intends to support them.

This doesn’t mean vSphere is being back-burnered. Monday morning did see an announcement of the company’s AppDefense application endpoint security system being baked into a new “Platinum” SKU of version 6.7 of the vSphere environment. During a press conference here, senior director for cloud platform product marketing Mike Adams asserted his department’s view, at least with respect to application security, that “the foundation of what we do is vSphere.”

Later at that same press conference, VMware Chief Technology Officer for the Americas, Cameron Haight, suggested that physical networking infrastructure today is too fragile to support the growing demands being placed upon applications, even when they are not evolving to newer architectures.  And those that are evolving are taking on size and scale that their own developers never anticipated.

The solution Haight advises comes in the form of what VMware is calling “Virtual Cloud Network.” Some of the providers in this network will include the company’s already established partners, including Amazon AWS and Microsoft Azure, both of which support the company’s NSX-T, an implementation of SDN optimized for applications. Through NSX-T, said Haight, an administrator can craft “consistent policies, both within your data center and within the private cloud, as well as some public cloud environments. So as workloads move between those different environments, you’re not having to change those policies that you spent a lot of time trying to configure.”

Pivotal Container Service (PKS), announced here last year, is VMware’s implementation of a “pure” or “vanilla” Kubernetes, as some executives here described it today, coupled with BOSH as its application deployment and release management toolchain. Unsurprisingly, PKS is built to run on NSX.

“NSX provides the environment to easily automate networking and security for rapid deployment of containerized environments,” Pat Gelsinger remarked. “It fully supports VMware PKS, fully supports Pivotal’s application service, and we’re also committed to fully support all of the major Kubernetes distributions, such as Red Hat, Heptio, and Docker as well. NSX — the only platform on the planet that can address the complexity and scale of container deployments.”

Note that Gelsinger refers to the product as “VMware PKS,” even though the “P” refers to sister company Pivotal.

“Spectacular Consensus”

In a keynote demo, Wendy Cartee, VMware’s senior director for cloud applications marketing, showed PKS running Kubernetes on vSphere, and particularly how PKS’ underlying NSX layer reveals network objects the moment that Kubernetes namespaces are spun up, by way of a YAML file devised by a developer. In this situation, each namespace enables isolated operations for individual users or namespaces.

The demo showed, within seconds, PKS assigning a logical router and logical switch to the namespace. In other words, PKS created the creation of network resources in parallel with the Kubernetes orchestrator spinning up clusters.

Commented VMware Chief Technology Officer Ray O’Farrell, “The developer went in, using Kubernetes APIs and infrastructure they’re familiar with, added a new namespace, and behind the scenes, PKS entirely took care of the network — a combination of NSX and what we do with PKS, to truly automate this function.”

It was a demo that certainly the entire crew had to have rehearsed at least once. So the fact that CEO Gelsinger’s reaction came as a prelude should not diminish its deeper meaning:

“Kubernetes is quickly, maybe spectacularly, becoming seen as the consensus way that containers will be managed and automated,” he told the audience. “It’s the framework for how modern app teams are looking at their next-generation environment, quickly emerging as a key to how businesses build and deploy their applications today. And containers are efficient, lightweight, portable — they have a lot of values for developers.

“But, they need to also be run and operated like any infrastructure challenges as well,” Gelsinger continued. While the update and lifecycle management process for an application accelerates with containers, he went on, “we also have these infrastructure problems. And the one thing I want to make clear is, the best way to run a container environment is on a virtual machine. In fact, every leader in public cloud runs their containers on virtual machines… Google and all major clouds run their containers in VMs. And simply put, it’s the best way to run containers. We have solved, through what we have done collectively, the infrastructure problem.”

Consistency Where There Is None

At a Monday afternoon press conference of the company’s technology COO and general managers, led by CTO O’Farrell, I asked how they would expect developers of containerized applications intended to Kubernetes to implement NSX as their networking layer, without having to effectively unplug from whatever SDN networking overlay — for example, WeaveWorks — that they had already been using, without having to re-architect those applications.

“The idea behind NSX is, it’s an overlay,” responded Tom Gillis, VMWare general manager for networking and security, “and it creates simplicity… When there are networking constructs that exist for a narrow piece of the infrastructure — let’s say, for containers that will exist today and tomorrow and going forward — the value of an overlay is providing consistency across them.

“We’ve done a lot of work to integrate NSX into every major flavor of container and Kubernetes platforms that you are going to deploy,” Gillis told The New Stack, “and the benefit is, it just works. There’s no complexity, you’re not relying on developers to go and set up complicated enterprise policies and connectivity. It’s all built-in, so we achieve what we think is the core value prop [proposition] of containers, which is rapid deployment that comes with connectivity and security.”

During a panel session later Monday afternoon, however, a few VMware customers did express a modicum of grief — not overly pronounced, but still present nonetheless — with adapting an already containerized application for PKS and NSX. Specifically, they’re substituting an overlay meant to enable a clan of containers to message one another, with a grand networking platform capable of spanning a private cloud and two or more public clouds simultaneously. To say there’s “no complexity” may not be the same as saying there’s no effort. A highly distributed, microservices-oriented application may or may not need some subtle adjustments when it is intended to run on a platform utilizing NSX; and the fact that such adjustments might be necessary at all, puts the topic of re-architecture back on the discussion table.

It’s this association of PKS with NSX that may render this particular platform unique among the emerging crowd of Kubernetes PaaS initiatives that manage to spell “container” with a “K.” It may be plain vanilla Kubernetes, but there also appears to be chocolate syrup, whipped cream, a split banana, and cherries — and they’re not there to keep things ordinary.