KubeCon 2019: How can we make developers love Kubernetes?

Published on Dec 12, 2019

This was my second year at KubeCon and I had a blast. Everyone was so open to sharing their experiences, and I finally got to try a california burrito.

With 12,000 attendees, the convention center was packed with Kubernetes expertise. I wrote this post to share what I learned from companies on the cutting-edge of Kubernetes – in particular, how these companies are dealing with developer experience on Kubernetes.

Figuring out developer experience is a requirement for adopting Kubernetes

So you’re ready to go all-in on Kubernetes – you’ve containerized your services, you’ve evaluated all the different templating tools, you know all 41 kubectl subcommands – what’s left to do?

You need to get your developers on board.

Over and over, I heard variants of

We [the DevOps team] want to use Kube, but the developers aren’t excited about it.

There are definitely developers that have embraced Kubernetes, but as Kubernetes spreads, teams are struggling to onboard developers that just want to focus on their code.

Three recurring challenges

How should developers interact with Kubernetes?

Developer experience on Kubernetes seems to boil down to that one question.

Although everyone had different opinions on the ideal interface, three challenges came up repeatedly.

1. kubectl is hard to understand

Shopify built krane to help developers understand whether their deployments to Kubernetes actually succeeded.

While kubectl apply is great, it only tells you whether your deployment was accepted by Kubernetes. You have to monitor the deployment yourself to make sure the deployment didn’t fail. For example, your cluster might not have enough resources, or there might be a typo in the image name. Krane monitors these sorts of scenarios so that it can accurately inform developers whether their deployment really succeeded.

Krane also intelligently handles deployment order. It deploys resources in phases so that developers don’t have to think about tricky edge cases. For example, it deploys ConfigMaps first so that Pods don’t boot with old configuration values.

And, Krane only displays the minimum information developers need to know if things are going smoothly.

In short: Krane simplifies Kubernetes deployments so that someone brand new to Kubernetes can be productive.

2. Laptops don’t have enough resources

A side effect of Kubernetes is that if you want to run all your services for testing, you have to do it in the cloud. Kubernetes has made it super easy to create new microservices, but the average development machine just isn’t big enough to run all of them.

One developer described the sound their laptop makes when running locally as “an airplane taking off”.

There doesn’t seem to be a standard solution here. Some companies are using their CI system to create preview environments when developers make PRs. Others just create a development cluster and give developers kubectl access. Some even just test in shared staging environments.

3. Managing test databases is hard

Although moving to the cloud allows developers to get personal replicas of all services, replicating databases is still tough. The two problems I heard consistently are “how do I apply migrations to test databases?” and “how do I keep test databases in sync with production?".

I talked to someone who built “Databases as a Service” for their internal teams – database schemas are stored in git repos, and can be referenced via Kubernetes annotations. When a developer deploys, a custom operator automatically sets up the database. So cool.

What’s next?

It’s easy to get caught up in all the potential of canary deployments and autoscaling and forget that we have to get developers on board to make Kubernetes successful.

Kelda is tackling developer experience on Kubernetes by streamlining local development. We make it easy to run your code on remote Kubernetes clusters so that your services aren’t hogging your local resources. But we also preserve the speed and simplicity of running locally. Check out the Kelda docs if you’re interested in seeing how we’re doing this!

I can’t wait to see what the state of developer experience will be like at Kubecon 2020!

Kelda Blimp is a drop in replacement for Docker Compose that runs in the cloud. Run your existing docker-compose.yml and continue using key features like Volumes and Port Forwarding with no modifications.

Related Article

Kube Explained: Part 2 - Containers

Read Now →

Get your guide to:
How Kubernetes breaks local development

Learn microservices’ biggest pain point of providing a good local development experience and how you can get the best of both worlds.