Retrospective: Why Was Cloud Foundry at KubeCon?
The Cloud Foundry community is on the cusp of spectacular innovation and achieving its goal of fully integrating open source Cloud Foundry with Kubernetes. We were very excited to be returning to KubeCon+CloudNativeCon after several years to showcase two new projects which we hoped would be of great interest to the cloud native community: Korifi, a new Cloud Foundry abstraction for the Kubernetes API and Paketo Buildpacks, a collection of Cloud Native Buildpacks.
But, before we dig into what makes these two technologies so important, some history.
Double helix
Cloud Foundry, as a technology, shares a lot of underpinnings with Kubernetes. They are both built to run applications reliably and efficiently at planet scale. They both share the DNA of Google’s Borg and have been relentlessly focused on a better dev and ops experience for practitioners. They achieve this by using containerization, effective isolation, and self-healing. Additionally, the two technologies are fully open source and governed by their communities.
Meld
Where they differ is in their approach toward actualizing the promise of a better developer experience. Cloud Foundry sets out to achieve its promise via a developer-first approach, where the focus has been on the source-to-URL contract. This means a developer working directly with the CF interface, with the rest of the underlying technologies and processes abstracted away completely. Kubernetes’s locus is set firmly around container scheduling and orchestration. The secret sauce for developers is the flat files written with declarative syntax describing the desired state of infrastructure, that the Kubernetes engine always drives toward.
The contrasts do converge though.
Direction
Despite taking divergent approaches, both Cloud Foundry as a community and Kubernetes with its vast ecosystem of related projects set out to accomplish the same end goal. That is, the ability for developers to build their applications into containers and deploy these onto infrastructure ― and to do that with observability, security, and other important aspects included in this build-and-deploy workflow. Our community has invested heavily in re-architecting Cloud Foundry to be built on Kubernetes primitives that have led to significant successes toward meeting this exact requirement.
Korifi is one giant leap into cloud native kind.
Launch
A PaaS abstraction, which offers a platform-based approach, has always been considered an excellent way to ease into a new technology ecosystem. Applying the Korifi abstraction to Kubernetes clusters can mean the same for software engineering teams that are working with Kubernetes. With little to no knowledge of Kubernetes required, the tool comes with defaults for any team that needs to hit the ground running with Kubernetes. Korifi provides the familiar CF push interface, while making use of various CNCF projects underneath. It works on public, private, and hybrid clouds and can also be deployed to edge devices, thanks to its small footprint — just as easily as any other platform. Underneath the hood, Korifi makes use of several Cloud Native Computing Foundation projects to provide load balancing, ingress, services, and metrics. It uses cloud native buildpacks to create containers.
This buildpack experience is near magic!
Magic
Buildpacks, which were pioneered by Heroku around the year 2011, are now making a comeback in a cloud native avatar. The CNCF incubating project offers the best means to containerize applications written in any language. The project aims to unify various buildpack ecosystems with its specification while also embracing standards meant to govern containers. Paketo Buildpacks are an implementation of the base CNB spec. The Paketo open source project provides production-ready buildpacks for the most popular languages and frameworks. So many tooling products (e.g., Waypoint, DigitalOcean App Platform, Korifi) are adopting Buildpacks for use in their build phase before deploying containers to a runtime.
The opportunity to make a lot more software engineering teams aware of these two projects and their capabilities was something that drove us heavily toward being at KubeCon.
Our investment in KubeCon was based on the belief that the conference offers the perfect platform for showcasing our technologies, especially because these tools enable a smooth experience for developers and platform operators. It is always our desire to broaden the horizons of the Cloud Foundry community. What better way to get interested folks to come forward and participate actively as contributors and maintainers than to exhibit the opportunities at the KubeCon floor?
We observed two key trends that we are proud of. The first one is that Paketo Buildpacks have received enormous traction in the DevOps community. There were a lot of folks who came up to us and enquired about the current state and future road map of the tool, while also discussing nuances about implementing Buildpacks for their current projects. The second trend is that a lot of folks recognize Cloud Foundry and welcome the same abstraction over Kubernetes. The tectonic shift that Cloud Foundry heralded for VMs is something that the larger developer would love to see implemented for their cloud native investments, too. So, that gives us something to look forward to in the upcoming year with Korifi.
