BrainBlog for Cloud Foundry by Jason Bloomberg
In my last BrainBlog for Cloud Foundry, I reviewed the history of the organization from its birth within VMware in 2009 to its current incarnation as a development platform for cloud native applications.
In the intervening years, Cloud Foundry evolved from a virtual machine (VM)-centric platform to a Platform-as-a-Service (PaaS) offering that the Cloud Foundry Foundation re-architected for containers running on Kubernetes.
Re-architecting for Kubernetes, however, is not the same thing as being Kubernetes-native.
The Cloud Foundry team understands the difference. To this end, they rolled out Korifi, a Kubernetes-native version of its popular Cloud Foundry platform.
Korifi offers the same experience that Cloud Foundry developers have come to love, only on the emerging Kubernetes infrastructure.
The power of custom resources
To build Korifi, the Kubernetes-native version of its platform, Cloud Foundry implemented its APIs directly on Kubernetes by replacing existing Cloud Foundry components with Kubernetes-native equivalents.
Two Kubernetes technologies proved essential for this revamp: role-based access control (RBAC) and Kubernetes custom resources. RBAC and Kubernetes custom resources mimic the Cloud Foundry platform’s orgs and spaces, respectively.
An org is a development account that one or more individuals can share. Spaces are shared locations that people can use for app development, deployment, and maintenance. Orgs consist of several spaces and map to identifiable Kubernetes pods.
Kubernetes custom resources extend the notion of a Kubernetes resource, which is a Kubernetes API endpoint that stores a collection of API objects. For example, Kubernetes’ pod resource contains a collection of pod objects.
Custom resources empower teams to customize a particular Kubernetes deployment. They allow customized Kubernetes deployments without the code-branching and maintenance issues so familiar from customizing earlier generations of software infrastructure and application platforms.
Instead, cluster admins can go about their work as normal, updating custom resources independently of the clusters they’re administering.
In addition, people can use standard Kubernetes tools like Kubectl to create and access custom resource objects the same way they would for built-in Kubernetes resources like pods.
Implementing Cloud Foundry APIs
Korifi leverages Kubernetes custom resources to implement Cloud Foundry APIs, thus supporting Cloud Foundry-compatible Kubernetes deployments that nevertheless run on standard Kubernetes.
For the Cloud Foundry developer, Korifi extends the classic Cloud Foundry experience. Developers can still write apps in their language or framework of choice and deploy with a single ‘cf push’ command as before.
In Korifi, in fact, a single cf push will call several separate API endpoints to orchestrate the push command, where custom resources specify the endpoints.
Developers are therefore able to orchestrate their own cf push commands if they prefer by manipulating the appropriate custom resources – without monkeying with the rest of the Kubernetes platform.
Working with Korifi
Many Cloud Foundry developers who are happy with the existing platform will continue to use it, leveraging Cloud Foundry’s BOSH toolchain for packaging, deploying and managing cloud software on IaaS or traditional (on-premises) VMs.
Other developers, however, will prefer to leverage Cloud Foundry while following the idioms and best practices of Kubernetes. Korifi provides this opportunity.
Korifi can integrate with other components of the broader Kubernetes ecosystem following the standard declarative approach familiar to Kubernetes users. Operators, Helm charts, and the rest of the Kubernetes way of doing things are now available to Korifi users.
Korifi also works well with Kubernetes-native tools such as Envoy and Prometheus, while also allowing teams to extend their use of existing CI/CD and observability tooling.
Korifi uses Paketo buildpacks to deploy apps as Open Container Initiative (OCI)-compatible containers, so that developers don’t have to deal with YAML or docker files directly (see my colleague Jason English’s article on Paketo buildpacks).
In many ways, Korifi developers have the best of both worlds: the power and simplicity of Cloud Foundry combined with the automated networking, security, availability, elasticity, and horizontal scale of Kubernetes.
For organizations with platform engineering initiatives, Korifi also serves as an internal developer platform (IDP). IDPs provide a standard approach to building and deploying applications across an organization – and Korifi is well-suited to serve the role of such a platform.
The Intellyx Take
There are two core audiences for Korifi: the seasoned Cloud Foundry developer who wants a native Kubernetes platform, and the newcomer to Cloud Foundry who is looking for a mature IDP for their Kubernetes deployments.
For the first of these audiences, Cloud Foundry provides two basic options: continued support of BOSH on VMs as well as the Kubernetes-native Korifi.
But Korifi is more than a way for Cloud Foundry to keep its fans happy. It also serves as a viable competitor in the IDP marketplace, even for developers unfamiliar with the long history of Cloud Foundry.
Copyright © Intellyx BV. Cloud Foundry is an Intellyx customer. Intellyx retains final editorial control of this article. No AI was used to write this article.
