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.
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 Pod s 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.
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 by streamlining local development. Currently, Docker takes up so much CPU and RAM on your local computer that it becomes slow and painful.
We made Blimp as a Docker Compose replacement in the cloud so you can easily scale up resources.
I can’t wait to see what the state of developer experience will be like at Kubecon 2020!
This story was originally published athttps://kelda.io/blog/kubecon-2019-how-can-we-make-developers-love-kubernetes/
