Ease Kubernetes Deployments with Cloud Foundry’s Korifi
Last year, the Cloud Foundry Community returned to in-person events at KubeCon+CloudNativeCon NA 2022 held in Detroit. Key takeaways from talking with attendees at our booth were the overall awareness about Cloud Foundry capabilities and continued need for those and the organic popularity of our projects, like Paketo Buildpacks. You can read the full report about our experience here.
So what are we up to for the KubeCon 2023 EU edition, being held at Amsterdam this week? Read on.
How the Cloud Foundry Community Is Organized
The Cloud Foundry community can be divided into two parts.
The first carries on the work of the decade-old, battle-hardened version of Cloud Foundry. This runs on VMs and is often termed as BOSH, the original project that was inspired by BORG, an internal project at Google. A large body of open-source contributors work on its different components, such as internal networking and application routing service brokers and other services for the platform.
A second part of the community works on projects that form the periphery of Cloud Foundry, extending the ecosystem. These include minor extensions of popular projects for use by the CF community, such as the Cloud Foundry Prometheus Exporter and Cloud Foundry Syslog Drain for Fluentd. Some projects that are developed with the Cloud Foundry core in mind may grow to have a broad application in a variety of engineering settings. Some examples are Stratos, Open Service Broker API, and most recently container image builder Paketo Buildpacks.
Ultimately, the two arms of the community help in contributing to projects that simplify the developer experience by providing essential abstractions.
The Guiding Light for Cloud Foundry’s Work
The purpose of Cloud Foundry is to provide application developers access to a best-in-class developer experience by enabling a self-service abstraction over infrastructure and services. In addition to running applications, it must also extend to building and maintaining app artifacts, allowing ingress, load balancing, and managing all the dependencies pertaining to the apps. At the moment, the community is hard at work in realizing this promise.
A major change from previous generations of Cloud Foundry is that Korifi is designed to be lightweight and capable of being installed on a local machine.
Kubernetes Abstractions: Our Main KubeCon Pitch
Kubernetes abstractions are particularly significant in the community, and are playing a pivotal role now more than ever. As Kubernetes adoption increases, so does friction. The Cloud Native Computing Foundation‘s 2020 survey found that 45% of respondents reported that complexity was the biggest challenge they faced when using Kubernetes.
This is where the work done by the Cloud Foundry community fits in. By introducing key abstractions to improve the developer experience when using Kubernetes, Cloud Foundry projects lead to more efficiency when creating and deploying applications. Cloud Foundry projects are not only improving workflows on the dev but also on the ops side.
Operations responsibilities are a vast area of software engineering. Examples of these include dynamic routing, log aggregation, access controls, containerization, and maintaining high availability. Cloud Foundry provides all of this functionality (and more) out of the box. This “batteries-included” approach is a much-needed experience in the Kubernetes realm.
The primary Cloud Foundry project providing Kubernetes abstractions is Cloud Foundry Korifi.
What the Community Has Achieved So Far
Korifi is an implementation of the Cloud Foundry API built on top of Kubernetes-native custom resources, with the goal of providing the Cloud Foundry to Kubernetes users, while tightly integrating with the Kubernetes ecosystem.
Since its first release, which happened about a year ago, a lot of progress has been made toward that goal. Korifi supports many Cloud Foundry flows, it allows users to run and manage apps and tasks, organize their workspace with orgs and spaces, and take advantage of user-provided services. Authentication and authorization are fully integrated with Kubernetes, so any user of the cluster can easily be added to Korifi. Artifacts are stored on standard container registries.
Korifi is designed to be modular, where any component can be swapped out for one that an engineering team finds more suitable. Container registries, ingress controllers, and other components that make up a Korifi installation can all be altered to suit bespoke needs. The way Korifi builds and runs its workloads can also be customized by implementing well-defined contracts.
The most recent release (v0.7) comes with labels and annotations support on all resources, better logging and the automatic deletion of older artifacts.
The Roadmap for Korifi
In the near future, the Korifi team plans to introduce various improvements, like:
- Improving the way builds are cached to reduce cf push times;
- Expanding the set of Cloud Foundry role types supported for authorization;
- Improving observability;
- Supporting more Cloud Foundry v3 API resources, like jobs and users;
- Support for Docker images.
The team is also exploring solutions to bigger challenges, like support for the Cloud Foundry marketplace and multi-cluster Kubernetes environments.
Paketo Buildpacks: An Unforeseen Unicorn
Paketo Buildpacks deserve a special mention here. It is an open source project and is a production-ready implementation of the Cloud Native Buildpacks specification. It is owned and governed by the Cloud Foundry Foundation.
At the Cloud Foundry booth during KubeCon + CloudNativeCon 2022 Detroit, we had a lot of adopters come over and discuss how they were using Paketo Buildpacks in their workflows and were excited to share their stories. Paketo Buildpacks have to be individually built and maintained for each programming language and framework. For example, there is a Java Buildpack that can help containerize apps built in the Java language. Similarly for Node JS, Python, Ruby, PHP, etc. The Paketo repositories are the best source of learning about the internals of each buildpack.
At the moment, the Paketo community is seeing considerable stability across a majority of the Buildpacks. They just completed the move to standardize the use of Jammy Jellyfish as the base Ubuntu distribution across all of their Buildpacks. The most requested feature by the community is support for ARM64 builds, which will be a top priority for the community. In addition, the Paketo community is committing to improving the transparency of their images for the benefit of teams that are using Buildpacks. These will take the form of security improvements such as SBOMs, signatures, provenance data, etc.
Apart from these major themes, there are initiatives to support a wider variety of operating systems such as the Red Hat Universal Base Image — which will make Paketo appeal to a larger base of users who expect to use RHEL in production. Supporting this will require an investigation into how the builders operate and support this within the framework of the base CNB specification. On the non-technical front, the project is looking to alter some parts of its governance structure and hold steering committee elections.
Come Join Us
If you like what you read and would like to chat with us, please make sure to visit the Cloud Foundry booth (S15) during KubeCon + CloudNativeCon EU at Amsterdam. We’re more than happy to discuss any of the Cloud Foundry projects. You will have a chance to meet with contributors to the various projects. Our Slack and social media feeds (Twitter, LinkedIn) are also open for you to join.
