Interview VMware has previewed Tanzu Application Platform, a bundle of Kubernetes packages which it claims will simplify application delivery – but its plans to run the existing Tanzu Application Service on Kubernetes have been abandoned.
The first thing to understand about Tanzu Application Platform (TAP) is that it has little in common with Tanzu Application Service (TAS). They are quite different things, making the similarity in name unfortunate.
TAS is based on Cloud Foundry technology, an open-source application platform whose tangled origins go back to VMware in 2009. It was then spun out to Pivotal Software, which handed the core software to the Cloud Foundry Foundation and was then re-acquired by VMware to become part of Tanzu. TAS, and Cloud Foundry, uses BOSH to package and deploy applications.
By contrast, TAP – introduced at the virtual SpringOne event this week – is a new set of add-ons for Kubernetes that aims to abstract much of the detail of deploying applications, so that developers can focus on their own code.
TAS isn't going anywhere. Honestly
We spoke to VMware's VP R&D Craig McLuckie, co-founder of the original Kubernetes project when at Google, who spent much of his time endeavouring to convince us that this is not the beginning of the end for TAS.
"Tanzu Application Platform is a natural complement to Tanzu Application Service," he says. "Tanzu Application Service is built on Cloud Foundry and is seeing a tremendous amount of use and continued growth with a lot of organisations that we work with."
That said, "A lot of organisations are already in a Kubernetes world or rapidly moving to a Kubernetes world," he adds, but "it can be a little overwhelming to build an easy road from the developer's IDE into a production context with Kubernetes.
"We've introduced the Tanzu Application Platform as a simple path... it starts with a fully curated set of dependencies that developers need to build modern applications, and if the community discovers that there is an exploitation of one of those pieces, to have the ability to update all the applications that might be affected."
Tanzu Application Platform aims to manage the software supply chain to ensure security as well as simplifying deployment
TAP is in some ways inspired by Spring, the Java application framework also sponsored by VMware. "What Spring has done is to allow developers to build something not tightly coupled to the production environment," McLuckie says.
Inversion of control means that infrastructure elements are bound to the code via a manifest, so that developers do not have to worry about differences between pre-production and production environments that have slightly different attributes, he tells us, which is the reason for Spring's dominance in the Enterprise Java world.
Mind your language
How do you install TAP itself? "TAP is just a series of packages," said McLuckie. "Much like Linux has packages, we've instituted a packaging systems for Kubernetes. We've taken a set of useful things and we offer them as packages that you can deploy into Kubenetes... you can deploy it into our Kubernetes, Tanzu Kubernetes Grid (TKG), which is well integrated into vSphere, but you could also run it on OpenShift, or GKE, or AKS, or EKS.
"You simply take the packages that we provide and drop them into the Kubernetes cluster, and you now have a build system that's able to produce well-crafted Kubernetes containers."
- VMware’s just given its best allies the tool to spread its Tanzu container creed
- VMware builds narrow one-way road to move its crown jewels towards cloudy subscriptions
- IBM has another crack at HCI, analysts say container-centric software-defined storage approach could shake things up
- VMware completes first year of Tanzu with Advanced Edition GA, announces magic tool for app modernization
How does the TAP technology relate to the open-source Kubernetes project, and associated open-source projects? "TAP is, wherever possible, a perfect extension of Kubernetes. When we encounter some significant deficiency in Kubernetes, our bias is to work through the community and make that thing available... TAP is built in, on and around the Kubernetes primitives. TAP is Kubernetes resource definitions, custom operators, that bring more intrinsic app awareness to the Kubernetes ecosystem."
VMware has been a big contributor to Kubernetes, McLuckie tells us, with open source technologies like kpack, Carvel and Harbor. "We have tried very hard to embrace this open engagement model where we work through open source. Spring itself is another fine example... if you dig into what the pieces are, they're mostly open-source technologies that we've contributed.
"Someone has to package those up, someone has to stand behind them, ensure that if the customer encounters an issue, those issues are dealt with. We see our role as stewards of a lot of technologies we are incubating in the open-source community and bringing those into a consumable form factor that addresses one of the biggest challenges our customers have with Kubernetes, which is simple confusion because it is overwhelming, there's so many options, there's so many points of integration."
How does the licensing work? "It will follow the rest of the Tanzu suite which is just indexed on a simple, how many cores of resource are you using? That has to work on premises and it also has to work on public cloud."
What though of Tanzu Application Service and the idea that it, too, would run on Kubernetes? There is a ton of history here. For years, the Cloud Foundry Foundation and its sponsor companies – including Pivotal/VMware – have been working to transition to Kubernetes.
That transition happened, though, and the Cloud Foundry Foundation now describes the project as "the cloud native developer experience for Kubernetes", even though the old CF Application Runtime and BOSH tools still exist. Will TAS run on TAP?
"TAS does not run on Kubernetes. TAS runs on BOSH," said McLuckie. "We have invested significantly in work to get TAS on Kubernetes, but what we discovered was, to get to the full Zen of TAS, the three Rs, that fully orchestrated repaving of your application, rotating of certificates, etc, was going to take a fair bit of work."
The company made the decision to create TAP as an alternative platform optimised for Kubernetes, rather than adapting TAS. "Our intent is to product TAS-compatible APIs on top of this eventually, because there is value in converging everything on a united baseline, but the reality for most of our customers is that TAS works pretty well for what it does.
"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? And allow organisations to decide for themselves when and if they want to make that transition."
TAS on Kubernetes: After hundreds of discussions with our beta customers ... we didn’t believe it would meet our standards for scalability, speed, security, and stability
The company's post on the subject is even more forthright: "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."
What does this mean for the Cloud Foundry project, if the founder of the technology is giving up on the Kubernetes transition? We asked the Foundation for comment but have yet to hear back.
The intriguing aspect here is that the high-level goals of TAP and TAS are not dissimilar; it is just that one runs on Kubernetes and the other does not. Presuming Kubernetes continues to dominate, that leaves the future of TAS looking uncomfortable, despite VMware's insistence that the project remains healthy.
The counter-argument is that if TAS and BOSH works well without the complexities of Kubernetes, it is hard to make a case for change. ®