Cloud-native platforms have set the standards for building and deploying software. They have enabled enterprises that didn’t exist twelve years ago to succeed in highly competitive markets. Cloud Foundry (CF), the open source cloud application platform, has been a driving force in that success, making it possible for enterprises to build, test, deploy and scale software significantly faster.
The perpetual challenge of ensuring cloud-native technologies are used efficiently and securely is an ongoing battle, and organizations will always keep a careful eye on increasing profitability. This has seen the emergence of Kubernetes as a way to quickly deploy and manage containerized apps in software development and production and raised questions regarding CF’s future.
The questions have become more urgent since VMware closed Pivotal Web Services (PWS), its fully-managed CF, in January 2021. Was this an indication that Kubernetes had “won”? Did this mean the “end” of CF? While PWS customers hurried to find a replacement, customers running their own CF installations were left uncertain.
About the author
James Hunt leads the research and design arm of Stark & Wayne
So is CF going to disappear? Not exactly because at its core, Cloud Foundry is an agreement between platform and developer, and this experience is still in high demand. CF offers to package, schedule, and run a developer’s applications if they abide by the 12-factor app methodology. This methodology covers everything from the codebase and dependencies to logs and admin processes. It ensures that the application layer on top of the platform can scale and thrive in a cloud environment. At the very least, it offers a unified application architecture that works the same across multiple programming languages.
This agreement sees cloud-native applications run predictably and reliably with a standardized approach. Other benefits of the 12-factor approach are written in some of the rules:
- “A 12-factor application crashes (or exits gracefully) if it cannot do its job”
- “A 12-factor application does not rely on the implicit existence of any system tools.”
The attributes these rules create are what make Kubernetes so popular, such as concurrency, disposability, and modularity, but this isn’t surprising as Kubernetes is also a cloud-native platform and is guided by the same rules as CF.
CF’s future is in changing and seeking to take advantage of Kubernetes. As RedMonk analyst Stephen O’Grady commented last year, the future for Cloud Foundry is how it “can provide abstractions above and around Kubernetes to improve the overall developer and operator experience.”
Recognizing that CF is more a contract than a singular platform, there are several systems that exist today in various development stages that follow CF’s platform-developer agreement. The first is “traditional” CF, the VM-based Cloud Foundry. This is deployed on VMs by BOSH, a virtual machine orchestrator for deploying, scaling, and maintaining apps on top of VMs from many different cloud providers.
Next is KubeCF, which containerizes BOSH releases for Kubernetes. This official Cloud Foundry Foundation project enables the consumption of the same BOSH releases that other CF teams use while supplying the most stable and faithful CF implementation for the popular container orchestrator.
There is another official CF project focused on Kubernetes called cf-for-k8s. This project takes a Kubernetes-native approach involving a massive change to both implementation and architecture. This project is at an earlier beta stage and looking to ship Open Container Images instead of BOSH releases. Additionally, as Kubernetes has a container runtime, CF’s Diego was removed, and gorouter has been replaced with Istio and Envoy.
As a consequence of the changes the cf-for-k8s project has made to CF components, the code the CF project team has to maintain has been greatly reduced. We also expect that, as the artifacts that KubeCF relies on stop being released, KubeCF will gradually adopt the production-viable components of cf-for k8s over time.
The final option, developed by Google, is more of an outlier, although it has the potential to be disruptive. It’s called kf and is a client-side reimplementation of the cf tool for Kubernetes (see what they did there?). Google is treating this as a migration tool, enabling a user to go from deploying source code to a CF straight to a GCP Kubernetes cluster on top of GKE, but it already supports many of the most commonly used commands and flags. It is a proprietary approach focused on Google products. Still, the idea of deploying and managing applications on a Kubernetes cluster with a simple shell alias is likely to have an appeal beyond Google.
As more innovation occurs where the benefits of both CF and Kubernetes are leveraged, we remain highly hopeful that CF on Kubernetes will mean that mid-market companies, and not just large enterprises, will benefit from the business advantages and experience that CF offers.
While it’s apparent that CF is unlikely to disappear, it’s essential to understand its continued business value as well.
CF offers a user experience that operator’s love
From a developer and operator perspective, the benefits are appealing. Cloud Foundry sits above the infrastructure (IaaS) layer, providing an abstraction of infrastructure services, and simplifying operations through a single platform. The way CF deploys apps with its cf push experience was famously described in the haiku: “Here is my source code. Run it on the cloud for me; I do not care how.” It’s an experience that operators don’t want to lose, as they don’t have to worry about such things as service discovery or where apps are deployed.
CF is open source and can reduce licensing costs
When considering faster ways to market, Open Source CF (OCF) can significantly reduce IT costs. As open source software is free to use, it reduces the costs associated with expensive license fees for commercial per-app instances. For organizations using a “CF-as-a-Service” cloud-based option, it is also an opportunity to ditch excessive infrastructure footprints and scrap seven-digit support contracts. OCF generally requires a larger operations team to allow for code contributions to OCF, but ultimately there are considerable cost savings to be made.
CF offers adaptability through automation for larger organizations
CF also delivers the nimbleness of CI/CD and DevOps to much larger organizations. So while CF can move an app quickly into production, it enabled, for example, a financial service to patch ZombieLoad attack in less than seven days with a setup of a few hundred Diego cells serving up to 40,000 apps. This project was also done without affecting the app teams or the running applications.
CF’s opinionated design reduces complexity, but still allows for customization
CF removes complexity and pain from the operator by being opinionated, but the assumptions and optimizations that it makes do not prevent it from being configurable and extendable. Its extensibility doesn’t allow for CF’s nature to change, but it can allow for precise customization. For example, we developed a “BOSH Splitter” tool that meant a customer could spread their maintenance tasks, such as scheduling stemcell (VM image) rotations, across multiple days and small windows instead of a single 2-day deployment.
CF has had a “multicloud-native” design from the outset and avoids vendor lock-in
Considering that not many businesses were thinking about multicloud when CF was designed as an open platform, CF can counter current vendor lock-in concerns very well. As an open platform, CF abstracts compute resources to create a standard way to deploy services and applications across different cloud providers. For enterprises using CF and adopting hybrid and multicloud approaches, we know that CF’s abstraction has allowed them to negotiate better service contracts.
CF establishes a foundation for agile app migrations
While CF is structured and opinionated, for companies considering their cloud-native journey, CF can enable effective app transformations once the groundwork is done. In our own experience, we’ve migrated over 1,132 non-production and production apps for an agricultural biotech enterprise without slowing or requiring the dev team’s attention. This project involved fixing all manifests and 271 Java pipelines and achieved without stopping workflow at all.
In a business world that demands accelerated change, Cloud Foundry is continuously evolving and responding to the demands of the software build, test, deploy, and scale cycle. This not only means faster go-to-market but maintaining the importance of the development feedback cycle. It’s not only predictability and reliability but also extensibility. It’s not just ease of use at scale; it’s cost-effective solutions. Cloud Foundry was designed to abstract complexity, so it should know how to change itself without you noticing the change.
