Helm User Profiles

13 views
Skip to first unread message

Matt Farina

unread,
Mar 6, 2018, 10:58:57 AM3/6/18
to kubernetes-sig-apps, cncf-kuber...@lists.cncf.io, kubernetes-...@googlegroups.com
As we start development on Helm v3 we wanted to collect the user profiles to aid us in writing and evaluating user stories. User profiles are similar to personas but are categories rather than example people.

The first version of these is now available. There are names, brief descriptions, priority order (no two things can have the same priority), and some other details.

I'm sharing so that the audience interested in Helm is aware and for others working on other elements in Kubernetes can see what we're doing.

Cheers,
Matt Farina

Brian Grant

unread,
Mar 6, 2018, 12:11:01 PM3/6/18
to Matt Farina, kubernetes-sig-apps, cncf-kuber...@lists.cncf.io, kubernetes-wg-contribex
Very useful, thanks.

Question:

Are these categories intended to include or exclude someone creating their own bespoke application, which they build and deploy via CI/CD? The examples of WordPress and MySQL are suggestive of off-the-shelf applications, whose developers may not care whether they run on Kubernetes at all, while engineers at Reddit and Ubisoft (to pick 2 users from Helm summit) probably care where their applications run.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-apps" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-apps+unsub...@googlegroups.com.
To post to this group, send email to kubernetes-sig-apps@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-apps/CAMPAG2p1poJ-0wuwxYOhatmhCQTw5EGTNf%3DuBJns9iaBpPBjsw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Matt Farina

unread,
Mar 6, 2018, 1:53:01 PM3/6/18
to Brian Grant, kubernetes-sig-apps, cncf-kuber...@lists.cncf.io, kubernetes-wg-contribex
These categories are intended to include those creating their own bespoke applications.

The role, which is described in a user profile, for someone developing the bespoke application is separate from the role of someone operating the application. In some organizations the same physical person will perform both roles and it other organizations they will be different sets of people.

The user profiles are targeted at Helm, which is a package manager, rather than the general case of application development and operation. I would expect related tools to have a similar but different set of user profiles shaped around what they're working on.

Does that help?


On Tue, Mar 6, 2018 at 12:10 PM, Brian Grant <brian...@google.com> wrote:
Very useful, thanks.

Question:

Are these categories intended to include or exclude someone creating their own bespoke application, which they build and deploy via CI/CD? The examples of WordPress and MySQL are suggestive of off-the-shelf applications, whose developers may not care whether they run on Kubernetes at all, while engineers at Reddit and Ubisoft (to pick 2 users from Helm summit) probably care where their applications run.
On Tue, Mar 6, 2018 at 7:58 AM, Matt Farina <matt....@gmail.com> wrote:
As we start development on Helm v3 we wanted to collect the user profiles to aid us in writing and evaluating user stories. User profiles are similar to personas but are categories rather than example people.

The first version of these is now available. There are names, brief descriptions, priority order (no two things can have the same priority), and some other details.

I'm sharing so that the audience interested in Helm is aware and for others working on other elements in Kubernetes can see what we're doing.

Cheers,
Matt Farina

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-apps" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-apps+unsubscribe...@googlegroups.com.




--
Matt Farina

Go in Practice - A book of Recipes for the Go programming language.

Engineered Web - A blog on cloud computing and web technologies.

Josh Berkus

unread,
Mar 6, 2018, 2:00:37 PM3/6/18
to Matt Farina, Brian Grant, kubernetes-sig-apps, cncf-kuber...@lists.cncf.io, kubernetes-wg-contribex
On 03/06/2018 10:52 AM, Matt Farina wrote:
> These categories are intended to /include/ those creating their own
> bespoke applications.
>
> The role, which is described in a user profile, for someone developing
> the bespoke application is separate from the role of someone operating
> the application. In some organizations the same physical person will
> perform both roles and it other organizations they will be different
> sets of people.

So, I've come across a use-case for Helm at several different user
sites, enough that it seems to constitute a major use-case: using Helm
as a minority component of a larger build pipeline.

I can't see how this use-case fits into any of the roles you've already
defined; those roles all seem to have hands-on use of helm in mind.
Which role would this fit into? I guess I'm looking for something like
"build system architect/maintainer".


--
--
Josh Berkus
Kubernetes Community
Red Hat OSAS

Brian Grant

unread,
Mar 6, 2018, 2:01:00 PM3/6/18
to Matt Farina, kubernetes-sig-apps, cncf-kuber...@lists.cncf.io, kubernetes-wg-contribex
On Tue, Mar 6, 2018 at 10:52 AM, Matt Farina <matt....@gmail.com> wrote:
These categories are intended to include those creating their own bespoke applications.

The role, which is described in a user profile, for someone developing the bespoke application is separate from the role of someone operating the application. In some organizations the same physical person will perform both roles and it other organizations they will be different sets of people.

No disagreement regarding the different roles, but certain design affordances may be made if the deployment environment were known.
 

The user profiles are targeted at Helm, which is a package manager, rather than the general case of application development and operation. I would expect related tools to have a similar but different set of user profiles shaped around what they're working on.

Does that help?

Yes, thanks.

Matt Farina

unread,
Mar 6, 2018, 2:37:56 PM3/6/18
to Josh Berkus, Brian Grant, kubernetes-sig-apps, cncf-kuber...@lists.cncf.io, kubernetes-wg-contribex
Josh,

I might be able to share how this fits...


So, I've come across a use-case for Helm at several different user
sites, enough that it seems to constitute a major use-case:  using Helm
as a minority component of a larger build pipeline. 
 
I can't see how this use-case fits into any of the roles you've already
defined; those roles all seem to have hands-on use of helm in mind.
Which role would this fit into?  I guess I'm looking for something like
"build system architect/maintainer". 

What is the build system person doing? Distributing application? Operating applications?

I'll try to illustrate with some examples.

Bitnami maintains some of the community charts. In doing so they have automation that picks up changes to apps and creates different build artifacts. One of those is a PR to the community chart for the changes. There's helm as a minority component in a larger system and it uses automation. The user profile this would fit under is the application distributor.

Another example could be the CI toolchain for the community charts repository. All changes to charts go through a series of analysis, including both static and runtime checks, and helm is one of many tools. It's used within scripts. Again, the user here is that of an application distributor because that's where the community charts fall.

A third example would be someone running a custom application for their company. The CI situation could be similar to that of the community charts but there are also steps to deploy to production. Here we have the role of application operator.

A "build system architect/maintainer" is a real person who is performing some roles described in the user profiles. The "build system architect/maintainer" may do different things depending on the organization they are in or the end goal of that system. Mapping these to the varying ways we work in companies is hard. Breaking them down into composable building blocks is easier.

Does that help?

Cheers,
Matt

Reply all
Reply to author
Forward
0 new messages