User research for Serverless/Functions as a Service Features in GitLab

We are planning on implementing new features in GitLab to help users with "Serverless" or "Functions as a service" workloads. Our options are very broad now as to what we could do but we have some scoped down ideas in:

https://docs.google.com/document/d/1qu-5qJTnc8xdq8IL1sRJNwc8cZUc67E9DPOxN8Sf5UY/edit

and

https://docs.google.com/document/d/1dNr5rIq_d7QBDo6xt0hNpd3ac12j-bsSu5hy-bihlL0/edit

What will likely happen is we will begin development on this before we can start research (due to timelines) but I'd like to start the research at least in parallel as quickly as we can so that we can inform some of our decisions based on real user needs. We may wish to build out some prototype of some sort based on our plans to get feedback from people on our current plan.

In 11.6 we will launch a new Serverless page in GitLab under the Operation's tab. This page will include a list of functions that users define in their serverless.yml file (found within their repo). Issue with mockups for 11.6

What questions are you trying to answer?

WIP:

• What do people currently do with regards to CI/CD for serverless?
• What serverless service are they using (AWS, Google, something else)?
• Do they also run Kubernetes?
• What types of applications do people use serverless for?
• What is the code architecture of serverless (one repo per function, multiple related functions in one repo, all company functions in one repo) and why did people make this decision?
  • Should the service name be shown in the UI? If users are using multiple serverless files, is it useful to include that within the UI? this vs. this
• How do users benefit from a gui overview of their functions? What is the primary use case?
• Are there usecases where events from GitLab (new issue, issue closed, MR closed etc....) should be passed to a serverless function.
  • What triggers do you want to invoke your function?

What assumptions do you have?

WIP:

• Users would be happy to use our solution built on top of knative/kubernetes so long as we make the setup process straightforward
• Users would want the code hosted in the repository
• Users would want to be able to edit triggers through a YAML file committed to the repo (as opposed to via the UI)
• Users need to set up lots of stuff themselves when doing serverless (eg. CI/CD)
• Users will benefit from some level of integration between code hosting and serverless
• Users will want to see their kubernetes pods autoscaling over time rather than only at one specific point in time Related issue

Ultimately, what would you like to get out of the research?

Serverless functionality added to GitLab should be informed by user needs. If we know what people will use we'll be able to more quickly get feedback on our plan.

What's the latest date that the research will still be useful to you?

Researcher progress

• Write survey questions.

• Import survey questions into SurveyMonkey. (Deadline: Friday 16th November)

• Test survey logic. (Deadline: Friday 16th November)

• Distribute survey to a test sample of users. (Deadline: Friday 16th November)

• Review answers and make any necessary amendments to the survey. (Deadline: Friday 16th November)

• Distribute survey to remaining users. (Deadline: Friday 16th November)

• Cleanse data and analyse survey results. (Deadline: Friday 23rd November)

• Schedule a wash-up meeting. (Deadline: Friday 23rd November)

• Add the study's key findings to the wash-up meeting calendar invitation. (Deadline: 24 hours before meeting)

• Record and facilitate the wash-up meeting. (Deadline: Week beginning Monday 26th November)

• Write report/blog post. (Deadline: Week beginning Monday 26th November)

• Add report/blog post to this issue. (Deadline: Week beginning Monday 26th November)

• May need to source additional recipients outside of the UX Research panel.

Report

https://docs.google.com/document/d/1TYddJ9CF10N8aNaGiUYV45P5Ilr7NpimTfn_YewdPn4/