Those still under the impression that VMware’s goals included propagating “vSphere Everywhere,” received yet another stark reminder Tuesday that the company’s infrastructure strategies run far deeper than selling its administrator platform.
At the European edition of the VMworld 2016 conference in Barcelona, VMware Chief Technology Strategy Officer Guido Appenzeller officially declared any strategy in which public and private cloud virtual infrastructures are brought together under vSphere’s oversight a “bad choice.”
This as part of the company’s announcement that its Q4 update to Photon Platform — its stand-alone containerization system — will not only support the Kubernetes container orchestration software but enable administrators to make dedicated instances of Kubernetes available to multiple users simultaneously, under a multitenant scheme.
“Many of you have started to use the clouds natively — and this word ‘native’ here makes a really big difference,” Appenzeller told attendees, making sure to include the “air quotes.”
“If, for example, you’re building on Amazon in a native way, you’re no longer using vSphere API or UIs to provision workloads, but now you’re doing it the Amazon way. So for example, instead of vSphere, you’re using [Amazon Web Services’] EC2; or instead of VSAN, you’re using [AWS] Elastic Block Storage. There are also many services which have on-premises [versions] that are not available in the cloud. If you want to use something like high availability or live migration, or highly flexible IP addressing, you can no longer do that [on public cloud alone]. But on the other hand, you have services like [AWS] S3, for which there is typically no on-prem equivalent.”
Where vSphere Stops and Something Else Begins
Appenzeller spoke to the need for enterprises to bridge the services gap between the benefits of public cloud platforms (such as elastic storage and flexible database services) and private cloud platforms (such as security and policy control). VMware’s partnership with Amazon AWS, announced last week, lifts the biggest political roadblock to bridging this gap, leaving only the technical ones.
But while that agreement paves the way for the NSX network virtualization platform to extend into Amazon’s public space, it doesn’t render all previous application management and deployment techniques immediately “cloud-native.”
Certainly, VMware is finding a way to “embrace and extend” containerization, and vSphere Integrated Containers (VIC) will be its way of extending its existing vSphere platform into the container space. But Photon represents the company’s appeal to organizations that have less — or no — legacy infrastructure that needs extending. And while Appenzeller told The New Stack in September that the percentage of customers with whom he’s spoken to which Photon may apply, is in the single-digit range, today’s admission about what those same customers are telling him now suggests the validity of their case may be irrefutable.
“Using clouds natively is different,” the CTSO said. “And if you were to go back to your developers and tell them, ‘Stop doing all that, and move everything back to vSphere,’ it would not only be very unpopular, I would argue it would be a bad choice for business. Because for certain applications, these native clouds actually have real advantages, and we should use them.”
That said, VMware’s marketing arm is making certain to tout vSphere as its “universal application platform,” extending not just between hypervisor-driven VMs and containerized workloads but Hadoop jobs as well.
“We’re using that [phrase] to describe our strategy around vSphere specifically,” said VMware Senior Director for VMware Software Defined Data Center (SDDC) Mark Chuang, speaking with The New Stack. “So that term ‘universal application platform’ refers much more to the runtime specifics. From a runtime perspective, whether it is 3D graphics, big data, cloud-native, machine learning, in-memory databases, Web scale-out applications — that whole gamut of applications out there — our goal is to deliver the highest performance, best possible experience on vSphere as the runtime, recognizing that different application types have different infrastructure [and] compute requirements.”
It’s a Small World After All
While the “container ecosystem” as we tend to refer to it here in The New Stack revolves around applications orchestration, Chuang argues that this level of orchestration is actually a separate topic from infrastructure management. Thus, from that perspective, vSphere does support Kubernetes.
“As it relates to things like Kubernetes or, you know, Mesosphere or — I don’t know, can I throw Swarm into that category as well? — the way we view it is, they can operate at different layers,” said Chuang. “We do have plans to support Kubernetes, and our goal is to say, if the request comes into Kubernetes and then, as Kubernetes passes it off to a vSphere cluster, our distributed resource management capabilities take over. So we actually view them as very complementary to each other, that you can actually layer these different schedulers.”
A vSphere environment uses Distributed Resource Scheduler (DRS) as its scheduling component and load balancer, and thus as its counterpart to a container orchestrator. When VMware first introduced both VIC and Photon last year, confusion about the distinctions between the two (even among the people first explaining them) led many, including customers, to wonder how applications orchestration would work in any VMware-branded environment.
At VMworld in Las Vegas some weeks back, the company made its intentions much clearer. VMware needed an all-containers environment that addressed the need for scalability in new data centers, and that need will be addressed by Photon.
“Think of these different products like NSX and VSAN in operational tools, in conjunction with Photon; think of Photon as leveraging those products underneath, but exposing a single, programmatic API,” said Paul Fazzone, VMware’s general manager for cloud-native apps, speaking to attendees. “Photon compute, Photon network, Photon container, Photon storage, Photon security. Now, through this API, IT can partition the infrastructure availability zones. Over time, this model will allow you to expand to form private cloud environments into public cloud environments as well.
“But it also allows you to expose this API to your development teams,” he continued, “so that you can go in and pre-provision a pool of resources to a development team, to a tenant. And that tenant ties back to a line of business — each of which has its own development teams. You could set them up each as a separate tenant, and each tenant could then have separate projects that are tenant-specific. And those projects — one can run Pivotal Cloud Foundry, another can run Kubernetes, another can run Mesos. Our goal is to make it very simple for IT organizations to provide that level of service to their development teams.”
This is the origin of the “Kubernetes as a Service” ideal. An application orchestrator can be delegated to each development team, which can run and manage it on its own terms. A network operator may then automate the process of provisioning a Kubernetes environment (or any other orchestrator, for that matter, but VMware is choosing Kubernetes as its model), and even spinning it down when it’s no longer necessary.
The plan certainly does away with the whole notion of destroying silos in order to join disparate departments together within organizations under a single platform. But there’s a chance such a plan will sell more readily to businesses that don’t want yet another cultural change every time it adopts a new product with a new methodology.
“We will actually support native, open source Kubernetes, Mesos, [and] eventually Docker Swarm,” Fazzone told The New Stack. “Just like you can make an API call or a UI call on vSphere today to create a new VM, with Photon, you’ll be able to go in, throw in a simple API call, create a tenant environment, and inside of that tenant environment, say, ‘Give me a Kubernetes cluster.’ And then anything you can do natively inside of that Kubernetes cluster running on bare metal, that will be exposed through the northbound interface to that cluster. So your portability into that environment will be more dictated by what the Kubernetes framework supports, versus what Photon is doing underneath the covers.”
VMware clearly believes in the continuation of a cordial relationship between developers and operators. It’s not DevOps per se, where both groups are squeezed together and told to collaborate or else, but it is a working relationship where one addresses the needs of the other. More to the point, VMware is looking to provide the system for automating the address and response process, so it is counting on the social and business structures of its customer companies to remain essentially the same.
“The IT department is needed more than ever,” said VMware’s Appenzeller on Tuesday in Barcelona. “But how we do IT changes in the age of cloud.”
Intel is a sponsor of The New Stack.