Arch-BOM sent a survey to edX and Arbisoft engineers in October 2020 to gain insight into devstack usage and pain points. This document summarizes the results of the survey.
40 people responded, of which 38 classified into a theme. |
There is a normal distribution (bell-curve) of self-reported expertise with devstack. |
Few people know how to add test data (but many think they could figure it out). |
How to change configuration is a mystery to about ⅓ of respondents. |
Most folks use devstack often (few times a week or more). |
About ⅔ of respondents run into devstack issues at least multiple times a month. |
People don’t use “make destroy” very often (a few times a year or never). |
Most people don’t re-provision very often. |
The following chart is ordered from slowest to fastest. While It is still difficult to Now that we have a clear owner of devstack, perhaps |
There is uncertainty around which commands to run when. We have big hammers (like reprovisioning all of devstack), but not clear regularly-needed hammers. |
|
Desire to have services work together smoothly out of the box. |
|
Folks are not empowered to solve their local problems. They resort to big hammers and are blocked by external help. |
|
Developers need the ability to provision their devstacks with “basic” test data for their most popular workflows. |
|
Developers seek decoupled services with consistent inter-service communications, and smaller footprints. |
|
|
Developers avoid |
|
Devstack usage patterns vary significantly across squads and developer seniority. |
|
Varying layers of technology add to devstack’s complexity. |
|
Decentralized devstack can be a viable solution, but underlying problems like provisioning and complexity still remain. |
|
|