Kubernetes boasts a unique number of different user personas. Like other infrastructure software, the platform operator is a key user. But Kubernetes users also include the actual end-user and the person writing code. An emerging and distinct role is now the person who is actually doing the application configurations. This “configurator” or “application operator” role may be a traditional IT operator or a developer.

The blurring of these roles is key to understanding why developers aren’t happy with the Kubernetes user experience. In this episode of The New Stack Analysts podcast, we explore how two Kubernetes Special Interest Groups (SIG) are taking into account all of the various user personas in order to help shape the user experience on Kubernetes. Guests on this episode include:

Subscribe: SoundCloud | Fireside.fm | Pocket Casts | Stitcher | Apple Podcasts | Overcast | Spotify | TuneIn | RSS Feed | Player FM

There are three ways to think through how to view the developer experience in Kubernetes that helps define the issues that come with determining how it can be improved.

Platforms : Kubernetes is essentially bits on a network. It is not meant for developers to use without a platform built on top of it. It’s why Red Hat OpenShift and other managed services are so popular.

: Kubernetes is essentially bits on a network. It is not meant for developers to use without a platform built on top of it. It’s why Red Hat OpenShift and other managed services are so popular. Operators : These are the “configurator” roles that the Kubernetes SIG group is defining. The question becomes, who does the configurations? It’s a role that has multiple personas depending on a host of factors.

: These are the “configurator” roles that the Kubernetes SIG group is defining. The question becomes, who does the configurations? It’s a role that has multiple personas depending on a host of factors. Policy: How policies are evolving as more people use the Kubernetes infrastructure within an organization.

It’s starting to become apparent that as Kubernetes matures, there’s going to be more to think about in terms of multi-tenancy and challenges that relate to security and cluster isolation, which relates to the issues developers face. Platforms are needed to isolate multiple teams that may be using the same cluster, for instance.

“One of the things that a lot of managed services are focusing on is helping companies effectively do multi-tenancy, get the right isolation,” Drew said. “And then also, of course, configuration management. [The] services are focusing on providing an opinionated approach, basically, so that it’s a little bit easier.”

Defining the cluster is increasingly a matter of using custom resource definitions (CRD) to provide an API for the Kubernetes API. But developing the CRD is a task that is still pretty new to most administrators. It’s in the work the Kubernetes SIG does to define personas that will lead to improvements for operators.

Red Hat and VMware are sponsors of The New Stack.

Photo by Jungwoo Hong on Unsplash.