Melpomene - Fotolia
The Cloud Foundry community's plan to create a unified developer experience between its PaaS framework and Kubernetes hasn't come together the way some stakeholders expected.
Two main projects that unify Cloud Foundry's VM-focused developer interface with a Kubernetes container infrastructure have been in development over the last year -- KubeCF, intended as a first step toward this integration, and cf-for-k8s, a more Kubernetes-native approach for the long term.
Some Cloud Foundry maintainers had hoped that cf-for-k8s would begin to take the lead on convergence between the two projects by this year, but as the community's virtual summit convened this month, that wasn't the case. The two remain separate, and cf-for-k8s has seen only incremental adoption, mostly among small development teams and greenfield companies so far, according to Cloud Foundry Foundation officials.
"I am mildly disappointed in the way the community has not accelerated through the convergence process," said Chip Childers, executive director of the Cloud Foundry Foundation. "It should have happened faster."
Bringing the two platforms together is important to existing users of Cloud Foundry, especially under VMware's former Pivotal portfolio. Kubernetes appeals to these users because it can more easily accommodate commercial and stateful applications than Cloud Foundry's more prescriptive platform. VMware's product based on cf-for-k8s, the Tanzu Application Service (TAS) for Kubernetes, is in beta.
"We have been experimenting and researching using [Kubernetes] to give our legacy apps and databases some of the advantages that the modern applications on TAS have," said Kerry Schaffer, senior director of information technology at OneMagnify, a marketing and advertising firm in Detroit that is a longtime user of the Pivotal Cloud Foundry platform. "With [Kubernetes], legacy apps can be containerized, so updates and patching can be performed during business hours."
While Kubernetes has some appeal, Schaffer said she'd prefer to have centralized management within Cloud Foundry rather than deal with two separate platforms.
At this point, Cloud Foundry is unlikely to capture more net-new users of cloud-native infrastructure platforms than pure Kubernetes, but it's critical that existing Cloud Foundry users have a path toward Kubernetes that maintains backward compatibility, said Larry Carvalho, an independent cloud computing consultant.
"VMware has to be very careful, because they need to get Tanzu accepted," Carvalho said. "If they don't get Cloud Foundry fully on Kubernetes, Tanzu starts getting a bad rap."
Cloud Foundry integration projects remain separate
In the last year, KubeCF has resolved most of the issues developers encountered as they worked to replicate the "cf-push" developer experience via Cloud Foundry's BOSH orchestration tool on a Kubernetes back end. IBM is using KubeCF to migrate its Cloud Foundry public cloud service to a Kubernetes infrastructure.
The more advanced project, cf-for-k8s, eliminates BOSH entirely and introduces Kpacks, Kubernetes-native updates to Cloud Foundry's historical infrastructure builder tools, called Buildpacks. The project has developed rapidly since its version 0.1.0 introduction in April 2020 -- as of June, cf-for-k8s had reached version 5.0, with support for Kubernetes versions 1.18 to 1.20 and Istio version 1.9.
But known issues remain. Kpacks remain at version 0.3.1. Version 5.0 is considered a breaking change to cf-for-k8s, and version 5.1.0, released this month, supports Istio service mesh version 1.10 and Kubernetes 1.21, but maintainers noted Istio does not support jump upgrades -- users must migrate first to version 5.0 before they can use version 5.1.
Moreover, community discussions this year have explored, but not fully resolved, multiple high-level architectural dilemmas that arise from attempting to merge two platforms that were designed around two fundamentally different forms of infrastructure in VMs and containers.
A "Vision for cf-for-k8s" document, last updated in May, summarizes the fundamental problem facing the Cloud Foundry community as it vies to keep up with Kubernetes.
"Other open-source ecosystems such as Kubernetes have been developing their own solutions to the domain areas of Cloud Foundry, in many cases moving much faster and with a bigger community," the document states. "Projects or technologies from those communities substantially overlap with the functionality of Cloud Foundry, from workload scheduling and execution to ingress routing and direct connectivity for workloads to identity and authorization providers."
Some Cloud Foundry community members said this month that they now have doubts about the long-term viability of the cf-for-k8s project.
"Frankly, I consider cf-for-k8s in a questionable state at the moment," said Simon Moser, lead architect for IBM Cloud Serverless and PaaS, in an interview. "Although it has a more Kubernetes-native codebase, it is not backward compatible, so it might be good for new greenfield deployments, but sadly not for deployment evolutions."
Another thorny issue for cf-for-k8s, according to the Vision document, is balancing the needs of users that prefer Cloud Foundry's tightly integrated, highly abstracted platform, and those that want to be able to access and customize the Kubernetes system underneath.
The tendency for Kubernetes deployments to consist of multiple clusters is also a fundamental difference between it and Cloud Foundry, and linking multiple clusters via Istio within cf-for-k8s presents another tricky set of problems.
"Istio's rather complex, and given that half the cf-for-k8s YAML was Istio config, I'd be intrigued to see if simpler solutions could be found," wrote one contributor in a comment on the Vision document in April (emphasis in the original).
Cloud Foundry community fades as IBM pulls back
Cloud Foundry Foundation annual reports show that while the Kubernetes community is already outpacing Cloud Foundry, contributions and revenue for Cloud Foundry are also in decline.
In 2019, 45,754 code commits were made to Cloud Foundry by 763 unique authors in 498 different repositories, and the Foundation's overall revenue was more than $5.3 million. In 2020, 40,403 commits were made by 576 unique authors to 497 different repositories, and overall revenue was $3.98 million.
Cloud Foundry's annual Summit had already shrunk noticeably in attendance during its last in-person event in 2019, and as with many organizations, put on more modest virtual events in 2020 and 2021. However, between 2020 and 2021, the list of the conference's vendor sponsors shrank from seven to five, and most notably, IBM went from a perennial platinum sponsor to gold this year.
In addition to swapping in a Kubernetes back end for Cloud Foundry in the IBM Cloud, the company is also using KubeCF to migrate Cloud Foundry users to Red Hat OpenShift.
"IBM will support KubeCF for the foreseeable future for the public cloud," Moser said. "For the on-prem space, IBM doesn't really have a Cloud Foundry solution anymore, other than the Cloud Foundry Migration Runtime ...The program there is clearly to move people from Cloud Foundry to OpenShift."
Childers acknowledged that the community has shifted from growth mode to a focus on maintaining long-term sustainability.
"Cloud Foundry for VMs is mature software, and not something that [vendor] companies will invest in heavily for marketing purposes," he said.
The Cloud Foundry Foundation has also overhauled its governance structure this year to reflect this, shifting from a Technical Oversight Committee dominated by top vendor marketers of the platform to one that includes more end users.
While contributions to the Cloud Foundry codebase have declined in number, they have started to come from more diverse sources -- about 75% of contributions used to come from Pivotal, now part of VMware, but VMware contributions now make up less than 50% of the total, Childers said.
"This is a natural part of the lifecycle," he said. "The Foundation has been set up over the last 12 months to focus on stability."
All eyes on VMware Tanzu Kubernetes integration
While IBM has focused on KubeCF, VMware employees have been by far the lead source of contributions to cf-for-k8s, according to GitHub records.
However, though VMware's TAS for Kubernetes was announced in May 2020, it remains at the beta stage and its last release, version 0.7.0, came in January. In the meantime, VMware employees are also contributing to a newer experimental project, Cloud Foundry Custom Resources, which is "exploring how the V3 Cloud Foundry APIs might be backed by Kubernetes Custom Resources instead of [Cloud Controller Database] CCDB," according to GitHub documentation.
To IBM's Moser, this project isn't a good sign for cf-for-k8s.
Simon MoserLead architect for IBM Cloud Serverless and PaaS
"I am concluding that they are still looking for a winner, and while a year ago I would have said cf-for-k8s is that winner, I wouldn't make that statement now," he said.
A VMware spokesperson didn't say which project the company's engineers will prioritize long term.
"VMware continues to lead discussions in the Cloud Foundry ecosystem to bring the proven Cloud Foundry developer experience to the world of Kubernetes," the spokesperson said in an email. "We have been collaborating with the open source community, including Cloud Foundry members such as SAP and IBM, on refining the vision for Cloud Foundry on Kubernetes and driving out the technical architecture to realize it."
VMware also declined to estimate a general availability time frame for TAS for Kubernetes.
"No doubt existing customers are interested in Cloud Foundry on Kubernetes, but for new customers it's a red flag if you don't focus on native Kubernetes," Carvalho said. "I would be working on migration tools [away from Cloud Foundry] if I were [at VMware] ... I don't see a good path for maintaining both [platforms] for too long."
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.