This post is the second in a three-month series examining the challenges of Kubernetes in 2020. For January, we examine the Kubernetes developer experience.
We’ve already established that the developer experience with Kubernetes isn’t as smooth as it could be. It’s a problem that hinders Kubernetes adoption — but also an opportunity for many of the companies that offer managed Kubernetes services and proprietary distributions. So what can be done to make it easier for developers to use Kubernetes in production?
For our second piece about Kubernetes and the developer experience, we talked with the chairs of the Cloud Native Computing Foundation’s Application Delivery Special Interest Group (SIG), Alois Reitbauer, chief technology strategist at Dynatrace, Lei Zhang, staff engineer at Alibaba and Bryan Liles, senior staff engineer at VMware. We discussed what’s at stake, what’s being done by the CNCF and others in the community to improve the developer experience and what other projects are on the horizon. Here’s a summary of our conversation.
Why should we care about developer experience in Kubernetes?
Reitbauer: Companies are making a huge investment moving to cloud native architectures. We want them to be successful, not have projects fail because they didn’t realize how complicated things are. That means we need to cater to a wide audience of developers with a diverse skill set, including people who are used to working on traditional enterprise applications.
“Naming things is actually one of the hard problems for people who write software.” — Bryan Liles, VMware
Liles: In the past six years, Kubernetes has become much easier to use. At first, getting a cluster up was hard. Now you can use Cluster API and put objects in your cluster to create a whole new cluster. We moved from just having pods and now we have deployments and replica sets. But developers don’t think on that level, and we need to get to the point where we think about applications and configurations — the things that matter to developers.
What is the CNCF doing concretely to improve developer experience in Kubernetes?
Liles: In the App Delivery SIG, we’ve been working on a set of guides that explain the different parts of the application and giving each application part names. Naming things is actually one of the hard problems for people who write software.
Reitbauer: We’re defining a joint language and agreeing on concepts. One of my favorite examples is that everyone in the cloud native space likes to talk about blue/green deployments and progressive delivery. But if you ask three people for details about what this actually means, how they would actually implement a blue/green delivery, you will get three different answers.
Part of App Delivery’s role is to say, if this is a standard concept, what does it actually mean? How does it work?
“Using Kubernetes should be more like driving a car than building a car.”– Lei Zhang, Alibaba
Zhang: The SIG is actively thinking about what is missing from the Kubernetes community. We know that all the developers are complaining about Kubernetes’ complexity, but we actually think that Kubernetes itself should be complicated. It’s a platform to manage the infrastructure layer systems. But that does not mean that every developer or operator should be interacting directly with Kubernetes. So in the SIG we’re thinking about what the right level of abstraction is.
We definitely think there are still a lot of missing pieces that would make it easier for developers to use Kubernetes without having to understand all of the underlying technology. When you drive a car, you only need to know how to use the steering wheel and the brakes, not how to build an engine or transmission. Using Kubernetes should be more like driving a car than building a car.
What are some develop experience initiatives you’ve seen in the larger community?
Liles: First of all, the interface improvements in the newest version of OpenShift are a big deal — it’s focused on the workload and the pipelines rather than just objects in Kubernetes. I’m also working on a project called Octant with the goal of creating a more developer-centric UI for Kubernetes. Instead of focusing on replica sets and pods, you have a workload. All the information that’s in Kubernetes is hidden to the novice. We need more people working on projects like this, rethinking how these interfaces should work.
What do you want to see more of in the future?
Liles: The CNCF does these webinars, and usually they are very project-focused. How to do continuous integration (CI) through Argo, for example. I’d like to see the CNCF take a step back with some of these webinars and talk about more about why. What do you hope to accomplish with continuous integration? Why does continuous integration matter?
In terms of Kubernetes specifically, it really should be easier for people to know what the next step is. CI and continuous delivery (CD) should be easy. We are making progress, but it needs to be much easier than it is now for someone to be productive using Kubernetes.
Reitbauer: I think having an opinionated approach is both helpful and a bit dangerous, because you have to balance the idea of standardization, which can help make it easier to be productive, with the need to avoid favoring one project. To extend the car metaphor, we all agree that cars should have a steering wheel and turn signals but we can pick the brand of car that we like the best. The same should be true for Kubernetes. Right now the only thing that’s agreed on in Kubernetes are at the basic build block level.
Zhang: The CNCF is the best home for standards, and doesn’t have to mean favoring one project. “Standards” can just mean standardized vocabulary, as Bryan mentioned before. For example, what is an application? Is it a container or a pod or a deployment? So that’s certainly something that the CNCF should take the lead in establishing.
“We need to cater to a wide audience of developers with a diverse skill set, including people who are used to working on traditional enterprise applications.” — Alois Reitbauer, Dynatrace
One of the reasons that people are confused in the Kubernetes community is that Kubernetes was built from bottom to top of the stack, focused on the infrastructure layer. There’s a huge gap between infrastructure concepts and developer/application layer concepts. I think it’s time for us to move some of the focus up to the application layer.
All three SIG chairs agreed that improving developer experience is not only on the community’s radar, but will likely be a major focus for the next year or two. As an example of what’s possible, Liles pointed to Kubeflow, which has dramatically simplified the experience for data scientists using Kubernetes for machine learning projects. “We need to apply the lessons we’ve learned from those projects to people writing web services,” he said.
Answers have been edited and condensed for clarity.
The Cloud Native Computing Foundation, Dynatrace and VMware are sponsors of The New Stack.