From Silos to Services: Cloud Computing for the Enterprise

Mar 10 2018   11:47AM GMT

Understanding the Variety of Kubernetes Roles and Personas

Brian Gracely Brian Gracely Profile: Brian Gracely


The Road to More Usable Kubernetes – Joe Beda

Depending on who you ask, you’re very likely to get many different answers to the question, “Who is the user or operator of Kubernetes?”. In some cases, it’s the Operations team running the Kubernetes platform, managing scale, availability, security and deployments in multiple cloud environments. In some cases, it’s the Development team interacting with manifest files (e.g. Helm or OpenShift Templates) for their applications, or integrating middleware services (e.g. API Gateway, MBaaS, DBaaS). Still other cases have blended DevOps teams that are redefining roles, responsibilities and tool usage.

Since Kubernetes orchestrates containers, and containers are technology that is applicable to both developers and operators, it can lead to some confusion about who should be focused on mastering these technologies.

This past week, we discussed this on PodCTL. The core of the discussion was based on a presentation by Joe Beda, one of the originators of Kubernetes at Google, that he gave at KubeCon 2017 Austin. While Joe covers a broad range of topics, the main focus was on a matrix of roles and responsibilities that can exist in a Kubernetes environment (see matrix image above) – ClusterOps, ClusterDev, AppOps and AppDev. In some cases, Joe highlighted the specific tools or process that are available (and frequently used) by that function. In other cases, he highlights where this model intersects and overlaps with the approaches outlined in the Google SRE book.

Some of the key takeaways included:

  • Even thought Kubernetes is often associated with cloud-native apps (or microservices) and DevOps agility, there can be very distinct differences in what the Ops-centric quadrants focus on vs. the App-centric quadrants.
  • Not every quadrants is as mature as others. For example, the Kubernetes community has done a very good job of providing tools to manage cluster operations. In contrast, we still don’t have federation-level technology to allow developers to build applications that treat multiple clusters as a single pool of resources.
  • Not every organization will designate these roles are specific people or groups, and some maybe be combined or overlap.
  • There is still a lot of room for innovation and new technologies to be created to improve each of these areas. Some innovation will happen within Kubernetes SIG groups, while others will be created by vendors as value-added capabilities (software or SaaS services).

It will be interesting to watch the evolution of roles as technologies like Kubernetes and containers begin to blur where applications intersect with infrastructure. Will we see it drive faster adoption of DevOps culture and SRE roles, or will a whole new set of roles emerge to better align to the needs to rapidly software development and deployments?

 Comment on this Post

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: