Epic: Two Workspace Classes on SaaS

[svenefftinge]

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.

Internal Signal

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 excludeFromMoreResources as 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 #10805 to check what will follow.

Tasks

• Register workspace classes that are supported by the workspace cluster #10842
• Support pvc workspace classes #11357
• Customers should be able to select their preferred workspace class #10843
• Allow specification of workspace class in project settings #10963
• Make ws-daemon workspace class aware #10981
• Update settings page with the latest design #11358
• Dashboard source workspace class names dynamically from server #11583
• Configure workspace classes for SaaS
• Remove fixed resources feature #11839
• Ensure workspace gets appropriate workspace class if created from a prebuild #11972
• Show workspace class in admin view #12048

Front conversations

[ajhalili2006]

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

[rohan-patra]

How would this affect users with unleashed/unlimited plans?

[rohan-patra]

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.

[csweichel]

We should generalise a tad and move to "workspace classes"

[shaal]

@csweichel that last link is not accessible to the public

[RafidMuhymin]

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?

[rohan-patra]

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.

[svenefftinge]

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.

[gtsiolis]

Posting some early design specs for future reference. Cc @Furisto @atduarte

v1	v2

[jimmybrancaccio]

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.

[gtsiolis]

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

[trumbitta]

"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".

[atduarte]

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.

[atduarte]

@Furisto Could you please include the updates to the Large and Standard limits, as well as their relation to the release, to the plan?

[kylos101]

Changing status to in-validation, as we're testing internally and socializing early access, and will use as feedback to plan GA. cc: @atduarte

[kylos101]

@atduarte as this is successfully in early preview now, can we move to done?

[edmondop]

When working on Rust, 50GB might not be enough for large projects such as arrow-datafusion