VMworld 2018: VMware Wants to Re-Architect Your Containers for NSX
One of the compelling advantages that Pivotal Container Service (PKS) has exhibited over the other container platforms in which VMware has invested, is that it promises to be an implementation of “plain vanilla Kubernetes,” requiring nothing special and no exclusive treatment from developers. In fact, add-ons intended for Kubernetes are supposed to plug into PKS just as easily as for any other CNCF-certified orchestrator. As a result, VMware officials have told attendees here at VMworld 2018 in Las Vegas all week, you don’t have to change or adapt your existing code or containers to run in PKS.
But if PKS is supposed to offer the benefit of NSX, the virtualized network infrastructure at the heart of every VMware platform for its private and hybrid cloud customers, then wouldn’t there be a reason for developers to want to make certain adjustments? This week, VMware senior officials gave The New Stack reason to believe they’d be delighted to see that happen.
Both PKS and the VMware Kubernetes Engine (VKE, the company’s recently announced public cloud-based, fully-managed service on Amazon AWS, coming soon to Microsoft Azure) are geared to provide what VMware is calling the “Kubernetes dial tone.”
“The Kubernetes dial tone we provide is 100 percent vanilla,” Senior Vice President and General Manager for Cloud-Native Applications Paul Fazzone told The New Stack, “whether you’re operating it on-prem with PKS or consuming and operating it in a public cloud environment with VKE as a SaaS service. They’re effectively identical in terms of developer interaction.”
The key differentiator, Fazzone went on, will be the platform’s operational model — how administrators and IT operators will oversee PKS. One element of that model is said to be a richer undercurrent of monitoring data, particularly for a monitoring service the company acquired last year called Wavefront, which officials here touted as more convenient and more adaptive to various container monitoring tasks than Prometheus.
If operators and IT personnel truly do receive richer performance data from PKS, coupled with NSX, than they would otherwise, then in the name of DevOps, wouldn’t it behoove them to share that performance data with developers, to help them improve the quality of their applications?
“Our objective is to help the IT operations team and DevOps teams free their developers to not have to worry about infrastructure, security, and operations,” Fazzone responded. “I don’t think it’s a light switch though. Are we there yet today? I don’t think so. I think there’s still some steps that require these teams to have a little bit of shared understanding of each other’s roles. Now I think, over time, that demarc will become a lot cleaner. But in the near term, I still think there are things that developers can’t simply stick their heads in the sand on. They have to be aware of some things. Kubernetes goes a long way to help you clarify that demarc and make that possible.”
VMware officials are on record (particularly at VMworld two years ago) as believing their platform should effectuate minimal change on the way IT departments are organized. In other words, you shouldn’t have to undergo radical “digital transformation” just to use vSphere or NSX. Here, Fazzone extends that stance in asserting that PKS does not need to bring about some kind of organizational sea change.
Still, he leaves the door open for a kind of workflow, perhaps triggered through Wavefront, where admins compel devs to pay more attention to certain performance metrics. That’s important, because even in an indirect fashion, it means that VMware is still open to the idea of containers that are ever-so-slightly VMware-flavored.
Of course, that’s still radically different from the company’s 2016 stance, which would have Docker’s tools silently supplemented under the hood, to produce specialized containers that were compatible with its vSphere environment. Because PKS is Kubernetes, the containers it manages are standardized Docker and/or OCI units. What would change, if anything, is what’s inside.
If suddenly there’s a richer infrastructure, including NSX and vSAN, underneath the orchestrator, then wouldn’t the wealth of signals operators and admins receive give them more excuses to close the Dev and Ops gap? And if so, wouldn’t that indirectly impact the architecture of containers built for that environment?
“I think that’s true,” responded Guido Appenzeller, VMware’s Chief Technology Officer for cloud and networking. “There’s sort of an aspect of, having more visibility — specifically if you give both sides access to it — can create a good platform where the SRE folks can work with the development folks to improve the project over time. I think we’re seeing this with Wavefront… We have these very large SaaS providers that are on Wavefront, where basically a lot of things show up on both the SRE dashboard and the developer dashboard. And if something goes wrong, they both look at the same data. That tremendously helps with communication.”
Fazzone then went on to cite how developers working with the standard Kubernetes ecosystem would probably employ Flannel as a network overlay for container connectivity. If an application under development had dependencies on databases being managed on containers hosted with an NSX-T networking infrastructure (referring to its edition of NSX for cloud-native environments), then if it continued to use Flannel for communication at the container level, it might become impossible for any policy model, no matter who supplies it, to govern these interactions at both levels.
“The developer shouldn’t have to know how to program NSX, or know what the security isolation boundaries are,” continued Fazzone. “But they should know that their organization has taken steps to unify the networking approach between the containerized applications and the traditional applications running in VMs, and take advantage of that ‘service’ offered by IT to extend the NSX-T support up into their container platform, versus just defaulting to the Layer 2 default that’s available in the open source community — so that their organization can realize that complete connectivity model in a consistent way.”
The Cloud Native Computing Foundation, Pivotal and VMware are sponsors of The New Stack.
Images by Scott M. Fulton III.
