Originally based on an interview conducted by The Register at Cloud Foundry Summit, The Hague, 2019. Source: theregister.co.uk
Pivotal Application Service for Kubernetes: Dropping the VMware Requirement
Pivotal’s alpha release of the Pivotal Application Service (PAS) for Kubernetes shipped with a dependency on VMware infrastructure—a deliberate shortcut to accelerate time-to-market. According to Ian Andrews, Pivotal’s senior vice president of products, that dependency will not survive into the generally available release.
“The only reason the alpha was tied to a number of components was to bring it to market quickly,” Andrews told The Register during the Cloud Foundry Summit in The Hague, Netherlands.
PAS is one of several certified distributions of the open-source Cloud Foundry platform. At the time of the interview (September 2019), no general availability date had been announced for PAS on Kubernetes. Andrews indicated that Pivotal planned at least two more preview releases before year-end: one at the SpringOne Platform conference in October and another toward the end of 2019.
Investor Pressure vs. Real-World Kubernetes Adoption
Pivotal faced significant investor pressure to accelerate its Kubernetes strategy, with critics arguing the company was falling behind the broader ecosystem. Andrews pushed back on the urgency, drawing a distinction between market narrative and actual production adoption.
“The urgency was more around understanding the long-term vision than an immediate need,” he said. “We’re still very early. Everybody is talking about K8s all the time, but if you look at who is actually using it in production, the list is much shorter. Our technology stack works incredibly well—we have customers with over 100,000 containers running on the current platform. If we forecast out three to five years, though, it seems clear that Kubernetes is going to be a de facto component in the architecture.”
Kubernetes as a Universal Infrastructure API
Andrews articulated a longer-term architectural view: Kubernetes will eventually recede into the infrastructure layer itself, replacing the distinct conceptual separation between VMs, storage, networking, and an orchestration tier sitting above them.
“In the future, Kubernetes will exist as an infrastructure API almost universally,” he said. “VMware has introduced Project Pacific. Now you have a consistent way to provision resources and infrastructure, do health management, updates, and scheduling. The operational complexity of the landscape goes way down.”
Project Pacific, announced at VMworld 2019 in San Francisco, integrates Kubernetes directly into vSphere. Andrews framed it as an early signal of a broader trend: “Today we think about VM hosts, storage, networking, and then Kubernetes as a thing that deploys on top of that. Potentially that becomes the only API that you see.”
The VMware Acquisition and the Multicloud Thesis
At the time of the interview, Pivotal was in the process of being acquired by VMware—notable given that both companies were already under common Dell ownership. Andrews used the opportunity to explain how Pivotal’s culture had historically differed from VMware’s, and why the two companies had converged.
“When Pivotal was created in 2012, both EMC and VMware were really trying to figure out their next chapter. VMware had built a franchise inside the data centre, but the public cloud story was very uncertain. For a time they were fighting against it. For the team at Pivotal, it was clear that most of the world would end up with some on-premises, some public cloud, maybe multiple public clouds—but we didn’t have an invested franchise we were attempting to protect.”
He noted that a similar dynamic played out at the container layer: “First VMware was defensive, and this is now a core part of their strategy. Over the last year we’ve aligned on the way we see the world. It’s multi-cloud, it’s container-centric. That opened the opportunity to come back as one company.”
Spring Framework Integration and Reactive Programming
Pivotal is also the steward of the Spring Framework, one of the most widely used Java application frameworks. Andrews acknowledged that PAS includes some Spring-specific integrations—primarily around distributed tracing and metrics collection—but emphasized that the deeper investment has been at the architectural level.
“We’ve been doing a lot of work in Spring to add support for reactive programming, that historically Java was very poor at,” he said. “That’s allowed us to start thinking about real-time stream processing with Kafka. If you compare the number of developers writing for Spring to the number of Pivotal customers, the first far outstrips the second. But if you choose to deploy on our platform, there’s a simplification.”
Competing on Multicloud Portability Against Hyperscaler Lock-In
Removing the VMware dependency from PAS for Kubernetes means the platform will be deployable on any conformant Kubernetes environment—including Amazon EKS, Google GKE, and Microsoft AKS. Each of those hyperscalers also offers its own managed application services, creating an obvious competitive tension.
Andrews argued that Pivotal’s multicloud portability is a differentiator the hyperscalers structurally cannot match. “We have great relationships with Microsoft, we’ve done a lot of engineering work with Google, we have lots of customers running on Amazon—but they also have products that sit in our space. Our ability to give customers a way to migrate between clouds is antithetical to their approach, which is ‘Get the workload on our cloud and lock it in there forever.'”
The Decline of Imperative Automation Tools
Andrews offered a pointed view on the future of traditional configuration management tools such as Chef, Puppet, and OpsWare—the last of which was where he began his career.
“The model we took [at OpsWare] was: whatever the human had been doing before, we’re going to put that in a script, they’ll be an agent, and we can execute those tasks,” he explained. “If you look at the state of the art today, there is no human building little command scripts that say, ‘When the container fails, respawn another container on a different host.’ It’s built into the system.”
The shift, in his view, is from imperative scripting to declarative intent: operators specify the desired state—for example, “always run three replicas of this container on separate hosts”—and the platform enforces it continuously, without human intervention for routine operations.
“It’s a different model of automation that is necessary for the current scale of operation. We’re now at a scale that is too massive for humans to touch. The paradigm that Puppet, Chef, or OpsWare represents is just completely ineffective,” said Andrews.
Key Takeaways for DevOps Engineers
- PAS for Kubernetes was in alpha at the time of this interview, with the VMware dependency flagged as a temporary shortcut—not an architectural requirement.
- Kubernetes as infrastructure API: The longer-term vision is that Kubernetes (or its successor) becomes the single control plane for compute, storage, and networking, reducing operational complexity.
- Multicloud portability remains Pivotal’s/Cloud Foundry’s core competitive differentiator against hyperscaler-native platforms.
- Reactive Spring and Kafka integration reflects a shift toward event-driven, stream-processing architectures in enterprise Java.
- Declarative over imperative automation: At cloud-native scale, desired-state systems supplant script-based configuration management tools.
This article is based on an interview originally published by The Register in September 2019. It reflects the state of Pivotal, VMware, and the Kubernetes ecosystem at that time. Significant changes have occurred since, including the completion of the VMware acquisition of Pivotal and subsequent portfolio changes.