Dashboard: User Types

[danielromlein]

About

One of the challenges with Dashboard is designing for the variety of user types. For effective UX, it's important that we know as much as possible about our audience as possible.

Goal

I'd like to here capture

1. Who the different intended users of Dashboard are, and how we'll refer to each of those categories.
2. How each of those user types differ (as well as what they have in common) in their use of Dashboard.
3. What each user type's main goals / concerns are as they relate to Dashboard (the more detailed, the better).

Proposed user types

1. Cluster Operators
   
   
   
   • Oversees the cluster: checks state of nodes and resources usage (if node conditions are met). In case there are not enough resources, they may decide to extend memory limits for the node or install more RAM. Mostly uses _Overview_ and _Nodes_ views.
   
   
2. Application Operators
   
   
   
   • In charge of applications' health – they want a detailed analysis. In case there are errors related to resources usage, they report them to cluster operator. Handle configurations
   
   
3. Application Developers
   
   
   
   • Create / delete / update applications (within one namespace?). Logs very important. Has advanced access to edit applications (YAML editor, ssh to pod from UI?).
   
   

[floreks]

From my point of view:

1. Person who only oversees the cluster, i.e. checks state of nodes, resources usage, if node conditions are met. In case there are not enough resources c. operator may decide to extend memory limits for the node or install more RAM. Mostly uses Overview and Nodes views.
2. Person who is in charge of applications health, updates, cleaning up. In case there are errors related to resources usage, he should report it to cluster operator.
3. Most often app. developer would create/delete/update applications (within one namespace?). Has advanced access to edit applications (yaml editor, ssh to pod from UI?).

It all depends on how user is actually using the cluster and what is his understanding of namespace, but imho these 3 points should be most often accurate.

[danielromlein]

Thank you @floreks! Incorporating these into the issue now. Left for us to document is what specific objects each of these user types would want to be able to see in the UI.

[cheld]

@romlein I like the roles you suppose. Below I tried to give a bit context:

I think in cloud environments, it is likely that one cluster is created for each application and namespaces are not used so much. Cluster Operators and Application Operators are most likely the same persons.

On premise, the environments are more traditional e.g. banks. Typically, there is a very strong separation between Dev and Ops. The Ops are very tough, very powerful persons. The applications are smaller, the usage of namespaces more likely. The cluster operators are also responsible to monitor the health of the application 24h/7, but only on a high level (running/not-running). If something is wrong they call in the Application Operators for analysis.
Traditionally, the applications are rolled out by cluster operators, but these companies (and cluster operators) are very unhappy with this approach, because it makes them slow. They are looking at Kubernetes because the cluster operators want to delegate responsibility to the application operators, to become more agile.

So overall, the user types are correct. I slightly modified their interest.

1. Cluster Operator

• Interested in capacity planning
• Hardware / nodes
• availability of applications (green/red)
• quick overview

2. Application Operators

• Detailed health analysis
• Rolling update of application
• Create new micro service
• configurations (config-maps, secrets)

3. Developer

• debug analysis (logs)
• inspect resource consumption of a single micro service

hope my explanation makes sense

[danielromlein]

@cheld very interesting point about public cloud and using one cluster per app – I hadn't considered that. At Apprenda we have two separate portals – one for operators and one for developers – so that context and learning how the K8s model differs from ours is very helpful in exploring how our design research might inform K8s. Thank you!

I've modified the issue descriptions slightly based on your input.

[cheld]

In the cloud

• Tenant separation build in IaaS layer
• Very simple to create new clusters
  => more likely to create separate clusters rather than sharing it.
• In addition, companies often have only one application. e.g. The company "eGym" has only the application eGym hosted in one Kubernetes cluster.

On premise:

• historically grown
• diverse set of applications, often duplicated functionality, e.g. because of acquisition and merges
• Most applications only used by a rather small number of internal users
• Often IaaS not available

One company (a bank) we talked to has 800 self written applications. For them it makes a lot of sense to share clusters

[cheld]

@romlein the reporting is in the other direction. The cluster operators report problems to the application operators. (high level, like "your application is not running any more.")

[floreks]

@cheld I guess it depends what is the actual issue. Cluster operator will see that some app is failing and he will inform app operator, but if app operator investigates it and sees that his app is failing because there are no resources on the node to run it then he will report back and cluster operator has to resolve it. I believe app operator won't be able to extend cluster limits and reserve more cpu/ram for his applications.

Communication should be bidirectional and dependent on the situation.

[bryk]

@cheld @dodwyer
Re "users create many clusters in the cloud": this is not that clear to me. There is only a few use cases where you'd create more than one cluster, e.g., to separate dev from prod environments, to geographically distribute failure domains or maybe when you are a large org that wants to separate cost centers.
In all other cases it is just better to have just one cluster for all your company and use namespaces for separation. With that you've got loads of benefits: better resource utilization, less operational overhead, centralized auth{z/n}, logging, etc.

[bgrant0607]

cc @kubernetes/docs, regarding audiences / user archetypes / roles

[bgrant0607]

See also #21 for use cases.

[danielromlein]

Thanks @bgrant0607! I'll go through and compare #21's listed use cases with what we have captured in our Google Doc Target User Types & Use Cases. If anyone would like to vote on priorities, just request access to edit the doc.

[floreks]

I think this discussion has come to an end. We can close it.