Blog

Just over a year ago, I shared the following message in the Six Feet Up #developers Slack channel: "Help! I'm falling in love with Kubernetes!!! I can't remember when last I saw something so well thought out!"

The tongue-in-cheek call for help is telling, almost as if it is shameful to embrace new tech buzzwords. One would hope that after 25 years of experience in the tech industry, I have a sufficiently developed buzzword filter! Additionally, Six Feet Up employs senior software engineers exclusively, and I was weary of resistance to the perceived complexity associated with Kubernetes.

Given the amount of growth Kubernetes has seen over the last couple of years, I consider myself part of the early majority, according to Everitt Rogers' five stages of technology adoption — possibly even part of the late majority. In December 2020, the Cloud Native Computing Foundation reported that 5.6 million developers use Kubernetes. At the time, this represented a 66% increase from the year before. In hindsight, my buzzword filter worked, after all!

What do I love about Kubernetes?

Firstly, the desired state of an application is described in plain text manifests, and Kubernetes deploys and maintains that state on any cluster — local or remote, bare metal or cloud. In short, it's declarative, and you don't have to worry about what commands to run to deploy an application or how to restart it when it crashes.

Why does that matter if you are a developer? Many things can go wrong between developing an application and deploying it. Kubernetes lets the developer describe any application in a precise and standardized way, leaving little opportunity for misunderstandings between the developer and DevOps team. Kubernetes is the language of deployment that helps developer and operations teams communicate with much less friction.

Second, Kubernetes easily deploys to clusters beyond your local host. Docker and docker-compose development workflows are stuck on the same host that you develop on. Even though IDEs make remote development possible, those options require a different workflow and added complexity.

Try to move your development environment from your laptop to another server on your network or an instance in the cloud. It won't be quick. With Kubernetes, changing to a remote cluster requires a single command.

Developer Experience (DX)

I like to think of developer experience (DX) as a user experience (UX). The number of interactions required to set up a development environment is a very accurate indicator of how good or bad the user experience is. The developer experience to set up a development environment at Six Feet Up can be better. The services we use in a typical web application were already containerized and configured with docker-compose. Building and running an application was further simplified to running make build to build images and make up to run the application. This doesn't sound all that bad.

Laptop hardware is static and doesn't scale with application requirements. Building multiple container images and running them alongside your IDE, browser, and communication tools can turn the noise of the overtaxed CPU fan and the frustrating groan in your head into a disturbing duet. Moving a local docker-compose workflow to a remote machine is not trivial, especially if you want to mount multiple volumes into a container.

Once you are set up locally, deployment should be your next concern. A CI/CD pipeline that runs tests, linting, and security checks and deploys a preview environment for end-to-end tests and manual QA creates an essential feedback loop in the developer workflow.

The infrastructure required to set up a CI/CD pipeline and preview environments may be the responsibility of the DevOps team. Still, developers must describe in detail how the application should run in those environments. Bootstrapping deployment can be particularly painful if it requires a different set of tools and configurations than what is used for the development environment.

Our main challenges in improving the developer experience were ensuring a developer has access to an environment with enough resources to run the application and standardize deployment across dev, QA, and production environments. My journey to find a solution quickly led to Kubernetes.