VMware has stated that the Cloud Foundry-based Tanzu Application Service for Kubernetes did not meet its standards, but despite this Cloud Foundry Foundation said that its Kubernetes transition is alive and well.
The terminology is confusing, especially as VMware calls all its developer platform stuff Tanzu, so bear with us. Tanzu Application Service (TAS) is the Cloud Foundry-based platform that does not use Kubernetes. TAS for Kubernetes is that platform adapted to run on Kubernetes. Tanzu Application Platform (TAP) is nothing to do with TAS, but is VMware's latest effort to simplify deploying applications to Kubernetes.
Cloud Foundry, stewarded by the Cloud Foundry Foundation, is a technology for deploying and managing applications that abstracts many of the details, enabling developers to focus on application code and giving operators automated scaling, load balancing and other features.
VMware is therefore closely associated with the project, though other companies such as IBM, SUSE, and SAP have also been involved and are members.
A few years back, the trend towards Kubernetes led to general agreement that the Cloud Foundry system should be ported to run on Kubernetes rather than VMs, and in July 2019 Rob Mee, then CEO of Pivotal, told The Reg that migrating the Pivotal Application Service, based on Cloud Foundry, to Kubernetes was a top priority. "As Kubernetes becomes a standard API for infrastructure, and that's the way we see it going, it does make it easier for us to run anywhere that Kubernetes runs," he said.
Following the VMware reacquisition, Pivotal Application Service became TAS, and TAS for Kubernetes was under development. In early September, though, VMware changed tack. "When we launched the Tanzu Application Service for Kubernetes beta program in 2020, the goal was to enable a consistent, multi-cloud experience and TAS-like outcomes on top of Kubernetes," said VP of Product Management Graham Siener.
"Nonetheless, after hundreds of discussions with our beta customers, we determined that the Tanzu Application Service for Kubernetes approach wouldn't allow us to leverage and expose the key declarative primitives that make Kubernetes and its ecosystem so powerful. We also didn't believe it would meet our standards for scalability, speed, security, and stability, nor would it deliver the kind of developer experience our customers have grown accustomed to. So, we pivoted."
The pivot was to invest in the original TAS and scrap the beta of TAS for Kubernetes. "Our expectation is that customers will continue to run their mission-critical apps on Tanzu Application Service for years to come," Siener said.
VMware's Craig McLuckie, VP of research and development, confirmed this to us when TAP was introduced, saying: "The Windows experience in TAS is very good and a lot of our customers have a high density of Windows-based workloads... the system creates value that it would be difficult to reproduce in the Kubernetes ecosystem. So why not preserve that?"
'It is inaccurate to say that VMware is giving up on transitioning traditional Cloud Foundry to Kubernetes'
Where does that leave all the work done to migrate Cloud Foundry to Kubernetes? McLuckie told us that "our intent is to produce TAS-compatible APIs on top of [TAP] eventually" but following the pivot this seems unlikely to be soon.
Cloud Foundry Foundation technical operations manager Chris Clark told us: "It is inaccurate to say that VMware is giving up on transitioning traditional Cloud Foundry to Kubernetes.
"While the launch of TAP as a parallel platform to TAS indicates their immediate need for a Kubernetes native platform, there is still an ongoing effort to deliver a feature-complete Cloud Foundry experience on Kubernetes...
"The failure of a single effort intent on bringing a full featured Cloud Foundry to Kubernetes does not mean Cloud Foundry is in trouble, or that bringing Cloud Foundry to Kubernetes has failed."
- VMware’s stack heads to Arm architecture – out on its new two-faced edge
- VMware's K8s challenge advances with Tanzu Community Edition
- VMware to kill SD cards and USB drives as vSphere boot options
- Break out your emergency change process and patch this ransomware-friendly bug ASAP, says VMware
A complication is that there are two separate open-source projects for Cloud Foundry on Kubernetes – KubeCF, primarily sponsored by IBM and SUSE, and CF-for-K8s, sponsored mainly by VMware. Angela Chin, senior engineer at VMware, said in August that "we have decided to pause our contributions to the cf-for-k8s project" just ahead of the official blog about ending the beta of TAS for Kubernetes.
Clark noted that "multi-company open source projects embrace ambiguity and change," suggesting that the impact of VMware's pivot has been considerable.
CFF leader leaves: 'You're essentially at the whims of competitors that are finding ways to collaborate'
The post of executive director at Cloud Foundry Foundation is vacant, with the departure of Chip Childers to become chief architect at Puppet (where he joins CTO Abby Kearns, another former executive director of the foundation). Childers had been at the foundation since its formation in 2015.
"I needed to get back to a position where I'm shipping commercial product and services," he told us.
He hinted at conflicts in the Foundation, although these are to some extent inevitable. "You're essentially at the whims of competitors that are finding ways to collaborate and sometimes not finding ways to collaborate," he said.
He also said that while the direction of the foundation had not changed, "projects have lifecycles. It has reached the point where it did not require someone in the executive director role. It's going to be appropriately supported by the broader Linux Foundation."
The good news for Cloud Foundry enthusiasts is that the future of TAS and the old-style variant of the technology seems well assured. McLuckie emphasised this point to us, saying that usage of TAS is growing and "seeing a tremendous amount of use." Whereas two years ago Pivotal was hastening to move it to Kubernetes, it seems that VMware now makes a virtue of it not being on Kubernetes. ®