Kubernetes can bring massive improvements to a company’s infrastructure and deployment processes. Yet, Kubernetes (K8s) is quite tricky for end developers to understand completely; the platform often requires specialists to operate.
So, DevOps owners rise to the challenge to wrangle Kubernetes and developers focus on writing code. However, separating roles in this manner could bring adverse side effects; namely, developers have decreased visibility into service performance and availability.
A UX layer or dashboard for Kubernetes could bridge the gap between groups, providing developers a better window into their services and helping teams speak the same language.
I recently met with William Morgan, a vocal K8s advocate and CEO of Buoyant, creators of the popular open source Linkerd service mesh and the upcoming Dive.co. We discussed the problems developers face today with K8s and how a developer experience emphasis could resolve K8s accessibility hangups.
The State of Kubernetes Accessibility
“I’m a big believer in Kubernetes; it’s pretty well-designed,” says Morgan. “But it’s not without a significant cost.” One cost is dealing with a good deal of complexity. It’s not impossible to manage, yet it may necessitate specialists and the separation of roles.
Morgan sees two audiences involved here. First, we have the platform owners. These are site reliability engineers (SREs), or DevOps leads, who operate K8s. They absorb the complexity, managing custom resource definitions (CRDs) and so forth. On the other hand, there are the end-developers. Their job is to write code and get it into production.
Two Ways Companies Approach Developers + Kubernetes
So, how do these two groups get on the same page? According to Morgan, it varies from company to company. He recognizes two vastly different approaches:
- “All developers must become K8s experts!”
- “No need to learn K8s. Keep your head down and code!”
In the first approach, a company will mandate all developers to learn the ins and outs of Kubernetes. The advantage here is that developers are more aware. However, it requires learning in-depth information that ends up being pretty irrelevant to a developer’s day-to-day work. As Morgan describes, “having to understand those details seems like a crazy approach for companies to take.”
On the polar end, some organizations will hide everything from developers. They only require them to focus on their service development, utilizing an abstracted UI or platform-as-a-service to deploy code. Just as the average driver doesn’t repair their car, the average developer shouldn’t obsess over deployment infrastructure. They just want “to push the pedals and turn the wheel,” Morgan says.
K8s UX Layers Empower Service Owners
In an ideal world, developers are empowered as service owners. “They aren’t just writing the code and handing over the wall, but they are deploying it, monitoring it, and on-call for it,” says Morgan.
This aspiration is a big part of the DevOps mission of “you build it you own it.” Hiding Kubernetes away entirely from programmers likely isn’t feasible and could work against this ideal.
“As a developer, there’s inevitably some amount of K8s you’re going to have to be exposed to,” says Morgan. “Teams need a shared vocabulary; developers need to understand concepts like, ‘what is a pod.’”
To bridge the two groups, a K8s dashboard could sit on top of Kubernetes. Such a UI layer could help platform owners get a more concrete view and also provide developers with actionable insights. It could bring the other following benefits:
- Visibility: Grants control, as developers can see where services are running, or if they deployed successfully.
- Reliability: A dashboard could showcase uptime percentages for services to measure the availability and reliability of code, also helping SREs monitor service level objectives (SLOs).
- Multi-service: This could help express information about a service for others to expose.
- Decoupled: Decoupled from a specific service mesh or cloud, a K8s UI layer could offer an agnostic plug and play capability.
- De-silo: Enhance collaboration by enabling teams to talk the same language.
Though service owners don’t need to know every nut and bolt of the system under the hood, they need to understand if deploys were successful, if code changes helped and how their service performs in production environments. To Morgan, empowering service owners with increased Kubernetes visibility could enable a healthy conversation between end developers and DevOps leads.
Cloud-Native Abstraction Is Relatively New
Abstraction layers like the one described above are nothing new; arguably, all computation involves abstraction in some sense. Morgan suggests that today abstraction is integral to the broader cloud-native trend. “We are still translating DevOps into a cloud-native world,” he says.
Software is still responding to a lack of hardware. With physical servers only removed relatively recently, cloud-native infrastructure has evolved quickly, spawning paradigms including containerization, microservices and virtual machines. Low-code platforms really take the concept of abstraction to new depths.
Cloud-native is necessary to meet new expectations, yet in this serverless world, developers continue to have less ownership over their networking and compute environments. This raises security implications, especially when dealing with user data. Without a physical line to your bare metal, service availability and reliability are inherently less of a guarantee.
On the flip side, Kubernetes is solving many issues. For example, “with K8s, it’s a lot easier to be in a multi-cloud world,” Morgan notes. “If this is your operational model, spin it up in GCP, AWS, Digital Ocean. It doesn’t really matter.”
As more and more abstraction feels inevitable, K8s paired with improved developer experiences may be necessary to empower service owners with more insights, thus bringing back some of the authority lost in the shift to cloud-native.
Whatever the Case, Kubernetes Must Result in Business Value
Many companies are probably in the situation of “Holy crap, we’ve adopted Kubernetes; now we need to make the company successful!” explains Morgan. After jumping on a trendy tech, these teams must now find business value in their Kubernetes adoptions. They must also balance new team dynamics.
Kubernetes is not the end-all answer. As Kelsey Hightower says, “Kubernetes is a platform for building platforms. It’s a better place to start; not the endgame.” Morgan adds that K8s is not a fit for every situation for numerous reasons. For example, he cautions use with very heavy batch workloads or scenarios where the engineering team is very lean.
K8s is also not a full cloud environment; it’s purposefully contained. This could be a blessing and a curse, meaning portability is increased, but you need your own glue to make it work. Kubernetes, and any extensions, should be added in service of making the company successful.
For Morgan, extending Kubernetes’ visibility with dashboard tools could bring significant benefits to empower teams. Such a layer could act as a middle ground between the two extremes of approaching Kubernetes ownership, making quasi-K8s experts of all, whether end developers, service owners or DevOps platform architects.