Enterprise developer and ops roles have shifted amid the rise of Agile and DevOps, but have resisted total convergence, prompting VMware to rework its DevOps platforms under Tanzu.
As of this month, VMware has put its first attempt at converging its existing Cloud Foundry-based Tanzu Application Service (TAS) with the Kubernetes container orchestration framework on ice, at least in the short term. For now, it will prioritize the Tanzu Application Platform (TAP) it introduced this month as its means of refining the developer experience for cloud-native infrastructure, according to company officials.
"Tanzu Application Service for Kubernetes doesn't make sense in its current form -- it's a closed system ... and people value extensibility in the Kubernetes ecosystem," said Graham Siener, vice president of product in VMware's Tanzu division, in an interview this week.
TAS for Kubernetes, introduced in 2020, had languished in beta for more than a year. Cloud Foundry maintainers at Cloud Foundry Summit in July expressed doubts about the future of the open source project, Cloud Foundry for Kubernetes (cf-for-k8s), on which that product was based.
As of this month, VMware has officially gone back to the drawing board with TAS for Kubernetes, and the community has begun to work on a more modular approach to cf-for-k8s based on Kubernetes custom resource definitions, Siener said.
Cloud Foundry customers use TAS to simplify PaaS management to the point where a handful of DevOps platform operators can support thousands of developer users, but enterprises want more flexibility to customize Kubernetes-based infrastructure, he said.
"The original cf-for-k8s effort intended to preserve a lot of the developer experience, but it made no claims of trying to preserve the operator experience," Siener said.
VMware TAP eschews full-stack developer ethos
VMware officials' comments as they introduced TAP at this month's SpringOne conference may have been eye-opening for anyone familiar with the history of DevOps. More than a decade ago, the DevOps movement gave rise to the concept of the full-stack developer, an engineer capable of both developing applications and managing their underlying infrastructure. For a time, the term "NoOps" generated industry buzz, and some tech prognosticators speculated about a future without system administrators or IT infrastructure operations specialists.
For small companies, particularly startups that can begin from scratch with cloud infrastructure, such a future may have arrived, and NoOps still has its adherents. But for big companies, the full-stack developer largely remains a myth.
"Spring ... brings an inversion-of-control model to developers that enables [a] separation of development from operations," Craig McLuckie, vice president of R&D at VMware, said in a SpringOne keynote presentation. "This means you don't have to worry about the instantiation, configuration and lifecycle management of the things that you build. You just get to focus on building them."
McLuckie compared full-stack developer knowledge to the concept of mechanical sympathy for race car drivers -- developers may get better results if they learn more about the underlying systems, but it shouldn't be strictly necessary to have that knowledge in order to use them.
VMware views development of an application as a separate behavior from operation of that application, even if the same person does both, said Ben Hale, technical lead for developer experience at VMware Tanzu, in an online SpringOne Q&A earlier this month.
"In some places the same people or small team are responsible for those roles, the canonical DevOps," Hale said. "In larger organizations ... we see those roles separate into Dev and SRE [site reliability engineering] teams."
Thus, while VMware's previous Cloud Foundry-based, developer-centric platforms minimized infrastructure complexity, but also flexibility, the new generation of DevOps platforms such as TAP takes into account the enterprise system administrators who have developed into skilled SREs.
With a platform team, nobody has to take care of all the complete [operations] of the infrastructure -- no developer wants that anymore.
Thomas MüllerCloud Foundry platform owner, Daimler AG
DevOps has taken this form in recent years within TAS customer Daimler AG, which manages internal platforms based on both Cloud Foundry and Kubernetes.
"With a platform team, nobody has to take care of all the complete [operations] of the infrastructure -- no developer wants that anymore," said Thomas Müller, Cloud Foundry platform owner at the vehicle manufacturer based in Germany, in a Q&A session during SpringOne.
Still, these platforms are an improvement over legacy approaches where the two sides of IT were starkly separated, and developers were often stymied by an ops-governed ticketing process at deployment time.
"There is no rivalry between the two [teams]" under the new system, Müller said. "Developers can release apps to production whenever they want."
This increase in developers' responsibility for production application performance also informed the design of VMware's TAP, which feeds production monitoring data to a developer interface.
A Daimler SpringOne presentation explores DevOps platform architecture.
Long-term DevOps evolution subject to debate
VMware's DevOps platforms may match with recent trends, but now the question for industry watchers is whether enterprise DevOps will continue to change and roles converge, and how. Will enterprises ever attain the vision of the full-stack developer? Should they?
There are potential downsides to maintaining separate dev and ops teams, even if they closely collaborate, said Christopher Condo, an analyst at Forrester Research.
"There are DevOps teams that understand how their platforms work and own a good percentage of the responsibility for how their code gets built, tested and deployed," he said. "DevOps breaks down ... when developers no longer have a responsibility to make sure code works well in production."
Some Java developers attending the SpringOne event were skeptical of moving away from full-stack developers as a long-term ideal.
"I'm not sure it's a great idea since it doesn't lead to as much product ownership from the teams," said an associate director of development at a professional services firm who asked not to be named because he is not authorized to represent his company in the press. "Some groups, like federal, healthcare and education [organizations], have strict rules about separating devs from production data, but personally I have always [had] a lot of involvement in the deployment of my systems."
Large companies with many systems also may not have the deployment staff available to learn the deeper details of every platform, the associate director pointed out.
"We've been pushing automation, and that usually falls on the senior developers in the team to set up, configure, monitor, etc.," he said.
VMware also has not let go of its long-term goal to provide a bridge between its Cloud Foundry and Kubernetes platforms, Siener said.
"We're trying to meet customers where they are," he said. "It's less about replacing one for the other and more about how we can deliver a platform that spans across those ... to make sure they don't have to make that choice before they feel it's necessary."
Beth Pariseau, senior news writer at TechTarget, is an award-winning veteran of IT journalism. She can be reached at [email protected] or on Twitter @PariseauTT.
