Epic: Two Workspace Classes on SaaS

svenefftinge commented 3 years ago

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 https://github.com/gitpod-io/gitpod/issues/10805 to check what will follow.

Tasks

[x] #10842
[x] #11357
[x] #10843
[ ] ~#10963~
[x] #10981
[x] #11358
[x] #11583
[x] Configure workspace classes for SaaS
[x] #11839
[x] https://github.com/gitpod-io/gitpod/issues/11972
[x] https://github.com/gitpod-io/gitpod/issues/12048

Front conversations

ajhalili2006 commented 3 years ago

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 commented 2 years ago

How would this affect users with unleashed/unlimited plans?

rohan-patra commented 2 years ago

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 commented 2 years ago

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

shaal commented 2 years ago

@csweichel that last link is not accessible to the public

RafidMuhymin commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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.

atduarte commented 2 years ago

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

gtsiolis commented 2 years ago

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

v1	v2

jimmybrancaccio commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

"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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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 commented 1 year ago

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

edmondop commented 9 months ago

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

gitpod-io / gitpod