Revisit premium runner fleet for Remote Development

Purpose

Re-visit previous attempts at using existing GitLab infrastructure to support Remote Development Environments. Determine what blockers exist to using Runner fleets to accomplish our initial goals and outline potential solutions (if any).

Scope

The outcome of this issue is not a working MVC in the product. One or more proofs of concept may be necessary but the ultimate scope of this issue is:

  1. Revisit previous blockers to using GitLab shared infrastructure to host a remote development environment for the Web IDE
  2. Identify whether those blockers still exist or if they have been solved over the course of the past 2-3 years
  3. List the reasons (if any) that our existing Runner fleet won't work
  4. Identify what we could do to overcome those challenges. For example, offering a more powerful Runner fleet configured specifically for this purpose (not optimized for CI) is an option to consider.
  5. Stretch If Runners (or potential future premium/tiered runners) could support the feature, what kind of cost would GitLab incur? This will help us identify the pricing model.

Details

We've looked into this before. The following links outline the approach we took and the challenges we faced in getting a runtime environment working in the Web IDE:

In summary, as much as I can follow, it appears we hit blockers in the areas of authentication, url mapping, file system access, and number of concurrent users due to limitations in the port ranges available.

While I don't see it listed, performance of the Runner fleet is a concern for more complex environments. A tiered solution may be necessary, but if the rest of the blockers are no longer an issue we could offer something like GitHub's Codespaces pricing matrix to ensure customers are getting the right balance of CPU/RAM power and cost.

Stretch goal: Costs

As we're evaluating infrastructure, it would be helpful to understand what costs come along with it. If, for example, remote environments can be hosted on shared Runners, how does that look when 10 developers are working 35 hours per week in them? We'll have to make some assumptions on the number of concurrent projects, downtime in between editing sessions, storage utilization, and probably more.

Edited by Eric Schurter