Achieving Production Parity and Local Development Workflows on Cloud Foundry with Kubernetes – InApps 2022

Close to the end of a very eventful 2020, a spontaneous conversation on social media caught my attention. Many interesting aspects about Cloud Foundry came forth in the banter that followed, but one particular aspect touched a nerve.

That exchange was referring to using Cloud Foundry locally and testing apps with a cf push experience on a developer machine. This post is meant as a response to these folks. We will acknowledge the vantage point from which these observations are made, show how Cloud Foundry is evolving to resolve the problem, and what the solution looks like.

But first: what does it mean to “use locally” and “install on your laptop”?

Any developer — enterprise or otherwise — would like feedback about the software they just wrote. Running their applications locally provides instant gratification, which is very important from the perspective of closing the feedback loop and ensuring the application works.

While these phrases — at a microscopic level — simply refer to ways by which to run apps locally on dev machines, they’re representative of a much larger and important goal — that is Production Parity. Keeping development environments as congruent to production environments as possible helps in many ways, fundamentally by preventing the (in)famous “it works on my machine” problem.

The 12-factor methodology advocates for dev/prod parity and also identifies the many ways in which dev environments may move away from production ones. The three reasons outlined are: time gap, personnel gap, and tools gap. Engineering teams benefit enormously from keeping dev environments the same as production environments. In creating the aforementioned feedback loop, sometimes developers tend to bend the rules around tooling and, in the interest of building a fast(er) feedback loop, end up creating an environment that is rather different from what runs upstream.

Several PaaS tools have adopted different ways to help provide parity between local dev and production environments. Some examples are OpenShift and MiniShift, Lando, Kalabox (Nanobox), Vagrant for PHP specifically, and the list goes on. Cloud Foundry (BOSH-based) also has a solution for this in the form of cf dev, but again, the similarity with production environments was considerably low. In spite of using these PaaS tools, the similarity between dev and prod has always left a lot to be desired.

By providing a complete abstraction over underlying infrastructure, Kubernetes provides a succinct advantage for developers. Applications will behave the same way when deployed to Kubernetes running on any infrastructure. Using Kubernetes on dev, staging, testing and production environments helps greatly with dev/prod parity. On the flip side, this introduces a quantum of complexity when deploying applications. And this affects small teams in a big way. Numerous examples of rising complexity in Kubernetes-based deployments are available.

Both Kubernetes and PaaS tools solve these problems to some extent, individually. Together, there seems to be a converged experience that might be the perfect developer experience, with a near-100% parity between dev and prod.

The evolution of Cloud Foundry to incorporate Kubernetes within its architecture was a paradigm shift. Cloud Foundry can now help provide its time-tested developer experience across a much broader range of infrastructure, by being able to connect to Kubernetes endpoints. This effort has taken shape as the cf-for-k8s project and it passed the important 2.0 milestone recently. With cf-for-k8s, developers can deploy their apps using cf push to Kubernetes-based infrastructure. This colophon will remain true irrespective of what target instance they’re using.

The uniform cf push experience can be a reality along the CI/CD pipeline and consequently test, staging, pre-production and prod environments will all deploy using the same set of commands; and build immutable artifacts using the same underlying tools, thereby providing the best dev/prod parity possible.

Without losing focus on the problem of local cf-based deployment, here’s a quick start guide for those interested in experiencing Kubernetes-based deployments locally using cf push.

Prerequisites

You will need the following tools to be able to complete a local installation of cf-for-k8s. Installation instructions have been linked to each of the tools listed.

Predominantly, the installation instructions follow the same process as you would install to any cloud-based Kubernetes cluster (GKE, DigitalOcean, Azure). There are slight variations, which are indicated below as appropriate.

This will give you a local Kubernetes cluster, which will have a Cloud Foundry PaaS experience on top of it. We believe this combination is very powerful, simple, and provides a complete developer experience — including the dev/prod parity that is a critical part of the developer workflow. It also solves the historically difficult problem of having a local Cloud Foundry deployment.

cf-for-k8s makes local development simple for all kinds of developers. This method of installing cf-for-k8s on local dev machines is endorsed by our community of open source contributors, commercial Cloud Foundry vendors such as VMWare Tanzu, and our system integrators.

Join our Slack community to collaborate with our contributors directly. You can also reach out to us on our Twitter and LinkedIn handles.

Lead image via Pixabay.