New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User Types #975

Closed
danielromlein opened this Issue Jun 29, 2016 · 12 comments

Comments

Projects
None yet
6 participants
@danielromlein
Contributor

danielromlein commented Jun 29, 2016

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?).

@danielromlein danielromlein changed the title from Description of User Types to User Types Jun 29, 2016

@floreks

This comment has been minimized.

Member

floreks commented Jun 30, 2016

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

This comment has been minimized.

Contributor

danielromlein commented Jul 2, 2016

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

This comment has been minimized.

Member

cheld commented Jul 4, 2016

@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

This comment has been minimized.

Contributor

danielromlein commented Jul 5, 2016

@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

This comment has been minimized.

Member

cheld commented Jul 6, 2016

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

This comment has been minimized.

Member

cheld commented Jul 6, 2016

@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

This comment has been minimized.

Member

floreks commented Jul 6, 2016

@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

This comment has been minimized.

Collaborator

bryk commented Jul 6, 2016

@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

This comment has been minimized.

Member

bgrant0607 commented Aug 29, 2016

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

@bgrant0607

This comment has been minimized.

Member

bgrant0607 commented Sep 27, 2016

See also #21 for use cases.

@danielromlein

This comment has been minimized.

Contributor

danielromlein commented Sep 28, 2016

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

This comment has been minimized.

Member

floreks commented Sep 29, 2017

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

@floreks floreks closed this Sep 29, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment