In the fall of 2020, VMware sent a curt email to all subscribers on its PWS — Pivotal Web Services — platform informing them that come January 15th, 2021, they would need to move all of their applications to … elsewhere.
Understandably, this caused a great deal of confusion among the PWS customer base. It’s not that easy to find a place where you can just `cf push` your application, let alone one with the breadth of marketplace services that PWS has. Well, had.
Perhaps surprisingly, it also engendered an unease amongst customers running their own Cloud Foundry installations. It didn’t seem to matter if you were running a home-rolled Cloud Foundry, based on open source components, Stark & Wayne’s own Genesis-deployed Cloud Foundry, or the official commercial Pivotal Cloud Foundry (later rebranded as VMware Tanzu Application Service). CF owners and operators the world over were left asking:
“Is this the beginning of the end of Cloud Foundry?”
Before answering that question, let’s define some terms and parse some syntax. What is Cloud Foundry?
Fundamentally, Cloud Foundry is a promise; a studiously adhered-to contract between platform and developer. The platform agrees that if the developer abides by a few rules, then their application can be packaged, scheduled, and run without the developer’s involvement. These rules are called “the 12 factors.” Applications that abide by these rules are dubbed “12-factor Apps.” Examples include:
“A 12-factor application has no state.”
“A 12-factor application binds a single port, which it gets from the environment.”
“A 12-factor application crashes (or exits gracefully) if it cannot do its job.”
Cloud Foundry then is about agreement. Anything that can take on and uphold that agreement can rightfully call itself a Cloud Foundry. As of today, there’s a couple of systems out there, in the wild, trying to do just that.
The first of those is also the oldest and most venerable: “OG Cloud Foundry.” The original one. Deployed on VMs, by BOSH. The components are BOSH releases, written in a pidgin of Go and Ruby, seasoned heavily with Java. In much the same way that penny-farthing bicycles came to be known as such, we now refer to this flavor of CF as “VM-based Cloud Foundry.“
Next up is KubeCF. The KubeCF team made an early call that Kubernetes was the way (Mandalorian reference anyone?) and that the best future prospects for Cloud Foundry involved replacing the BOSH-and-VMs with Kubernetes-and-Containers. However, they made a crucial (and technologically inspiring) decision to simply directly consume and re-purpose the BOSH release artifacts. This allowed for consumption of the same BOSH releases other Cloud Foundry teams were already releasing. KubeCF is now considered one of the most stable and faithful containerized Cloud Foundry implementations.
Another project called “cf-for-k8s” was created for running Cloud Foundry on Kubernetes. It’s core premise is to embrace Kubernetes ecosystem components and package internal Cloud Foundry components directly as containerized workloads to run natively on Kubernetes. VMware had also arrived at the realization that Kubernetes was completely dominating the platform and container orchestration world, and decided to start pivoting slowly off of a BOSH-and-VMs approach. However, since VMware is the main driver of the CF roadmap (and SuSE / KubeCF folks are not), they were able to set the priorities and ensure a re-targeting to a Kubernetes native approach. The Cloud Foundry core teams were now looking to start shipping Open Container Images as their released asset rather than BOSH releases. This was a massive change to not just the implementation but also the architecture. Diego (the VM-based Cloud Foundry container orchestration engine) was removed as Cloud Foundry didn’t need to lug around its own container runtime as this was provided out of the box by Kubernetes itself. The routing tier also got an overhaul, albeit one that was probably inevitable whether CF stayed VM-bound or not, using the Istio and Envoy technologies from the Kubernetes ecosystem. This further reduced the amount of code the core Cloud Foundry team themselves needed to maintain as projects.
As cf-for-k8s gains more beta adopters, and teams stop releasing these artifacts that KubeCF relies on, KubeCF will adopt components of cf-for-k8s as they become production viable. Eg. the composition of KubeCF will change to adopt these new container-first components. KubeCF serves as a vital bridge between VM-based and future containerized Cloud Foundry architectures.
And then there’s `kf` from the folks at Google.
`kf` is a client-side reimplementation of the Cloud Foundry `cf` tool, the primary means of interacting with the platform to deploy and manage applications. The goal is simple: with a simple shell alias you can go from deploying your source code to a Cloud Foundry (VM-based, cf-for-k8s, or KubeCF), and instead deploy your applications to a Google managed Kubernetes cluster, atop GKE.
Google’s looking at it primarily as a migration tool, but they’ve come surprisingly far in their support of the most commonly used commands and flags. It may seem weird and unconventional, but if you’re already a Google shop, either in the cloud on GCP, or on-premises via Anthos, it’s definitely a viable way forward. Our friends over at Engineer Better have had a good experience with it.
Because of the operational cost of VM infrastructure the solid and scalable CF on VMs has traditionally been viable only for massive organizations. We remain highly hopeful that a CF on Kubernetes option becomes viable so that the massive mid-market can also benefit from the advantages and experience of CF.
Ultimately, getting back to the main premise that Cloud Foundry is a promise between the platform and its developer-customers: We would not be surprised if someone came along and simply re-implemented that contract as a Kubernetes operator / controller, eg. directly using Kubernetes primitives. Then, with a single `helm install`, without bringing any additional tooling into the mix, or fundamentally changing how you manage deployments, you get a CF-compatible Kubernetes cluster. Developers can keep pushing their apps, either by hand or via CI/CD, and you can normalize your tool chain and defragment your execution runtime!
Now that’s a true win-win-win! (Owner-Operator-Consumer) ❤️
Spread the word
