gitpod
gitpod copied to clipboard
gitpod-io
Epic: Two Workspace Classes on SaaS
Summary
Provide users with the ability to select between two different workspace classes for all their workspaces. On SaaS, the options are:
- Standard (up to 4 cores, up to 8GB RAM, 30GB storage)
- ~XL~ Large (up to 8 cores, up to 16GB RAM, 50GB storage)
⚠️ Note that because of the storage size differences, a XL workspace can't be restarted as Standard, and neither can a Standard workspace be started from an XL prebuild.
Context
Different projects require different resources. To allow developers to fully leverage the power and scalability of the cloud, we want to allow for different workspace classes.
Value
Users will have access to better performance, that supports heavier workloads.
Acceptance Criteria
- SaaS users that don't have a "legacy" monthly subscription must be able to choose between the two options (Standard and XL) in the Account Settings.
- SaaS users that have "legacy" monthly subscriptions should continue to use standard or XL according to the
excludeFromMoreResourcesas they do today. - SaaS users must be billed according to the workspace class they are using.
- Workspaces must not fail to start because the backup is larger than the storage available in the chosen class.
- Users should be able to determine what is the class of a given workspace, and what was the class used to run a prebuild
Measurement
- % of workspaces that were XL.
Growth Area
Expansion.
Persona(s)
Users that have heavier workloads.
Out of Scope
- Self-hosted use case.
- Having different workspace classes share the same node pool, and similar optimizations.
- Per project or per workspace class.
See https://github.com/gitpod-io/gitpod/issues/10805 to check what will follow.
Tasks
- [x] #10842
- [ ] #11357
- [x] #10843
- [ ] ~#10963~
- [x] #10981
- [x] #11358
- [x] #11583
- [ ] Configure workspace classes for SaaS
- [x] #11839
- [ ] https://github.com/gitpod-io/gitpod/issues/11972
What about the storage for /workspace? Is it limited to 5 GB (like in Google Cloud Shell for /home/<your-gmail-username-over-here-probably>)?
What about the storage for
/workspace? Is it limited to 5 GB (like in Google Cloud Shell for/home/<your-gmail-username-over-here-probably>)?
I believe they allow 30 gb to persist in that directory and the allowed space in a running workspace might be higher but will be deleted when the workspace stops.
We won't be able to offer unlimited hours with this, so need to think about changes to our plans that are more usage-based than seat-based.
Currently, in the Personal plan, we get unlimited hours of usage and we can run up to 8 parallel workspaces. So currently, a user who has purchased the Personal plan gets 24 * 30 * 8 = 5760 hours technically. Now, if the plans get changed to be usage-based, then will a user get 5780 / 4 = 1440 hours if they enable 4X mode?
IMHO, the current pricing strategy is the biggest draw for Gitpod over something like Codespaces. I know that Gitpod also offers a host of other features including integration with Jetbrains (extremely useful), but the ability to just use Gitpod without worrying about how many hours I am using is so amazing for me as someone using it for personal projects, school, and contributing to open-source projects.
I would suggest something like the following: highest tier plan: unlimited hours on S and then x flexible hours per month to use towards more powerful instances following the pricing in the original post and if someone needs more flexible hours, they can purchase more.
Currently, in the Personal plan, we get unlimited hours of usage and we can run up to 8 parallel workspaces. So currently, a user who has purchased the Personal plan gets 24 * 30 * 8 = 5760 hours technically. Now, if the plans get changed to be usage-based, then will a user get 5780 / 4 = 1440 hours if they enable 4X mode?
We are going to fade out the existing plans. That means new users cannot subscribe to personal or unlimited plans anymore. Users who are today on such a plan cannot use different workspace sizes. If you want to use them and you are on a personal plan you'll need to switch to the new usage-based plan, that we are going release together with this epic.
Regarding taxonomy:
There has been an ongoing discussion regarding how to name what we have been calling "workspace classes" or "workspace sizes". Multiple options were explored:
- Workspace types — this one is problematic given that we already use it to differentiate prebuilds, images builds and regular workspaces
- Workspace instance types — this has a similar issue as "workspace types" and it's too long.
- Workspace sizes — there are concerns around completeness, as the "sizes" may have more differences other than the RAM/CPU/storage size (e.g. GPU, single core performance, storage type/performance). Specially because we plan to use the feature for adjacent needs of self-hosted customers (e.g. separating workloads by team/department; special workspace configuration; ...).
- Workspace classes — the original name we used, that already shows up in the code and data.
For simplicity, and since sizes didn't "stick", I propose we use "workspace classes".
My only concern is that it may not be very intuitive for SaaS users. If when collecting feedback or after launching we figure out that is the case, we can change the copy in our website while keeping the underlying technical mechanism named as "workspace classes".
Let me know if this is off-topic and we can discuss it elsewhere! I love the work done in those screenshots @gtsiolis - looks great!
Was there a reason we decided on two workspace classes? How come not 3? I ask because in v1 I see 3 dots so that's what got me thinking.
Hey @jimmybrancaccio, thanks for the feedback! 🙏
Was there a reason we decided on two workspace classes? How come not 3? I ask because in v1 I see 3 dots so that's what got me thinking.
The MVC starting point for this feature includes two workspace classes as described in the epic description and other internal documents[1][2][...]. See also relevant discussion (internal).
"Standard" confuses me a bit. How about using those labels to provide a bit more info about what the shorter ones mean?
About that, I find "XL / HIGH MEMORY" clearer than "M2 / LARGE", and I'd like to see something different from "SM / STANDARD" for the other couple.
Maybe along the lines of "SM / BASELINE SPECS" or "SM / BASELINE".
Was there a reason we decided on two workspace classes?
@jimmybrancaccio because we already have 2 workspace classes in production but one (the Large) is only available to a small fraction of the users.
@Furisto Could you please include the updates to the Large and Standard limits, as well as their relation to the release, to the plan?
Changing status to in-validation, as we're testing internally and socializing early access, and will use as feedback to plan GA. cc: @atduarte
@atduarte as this is successfully in early preview now, can we move to done?
When working on Rust, 50GB might not be enough for large projects such as arrow-datafusion
