Remote Development | Technical Direction and Server Runtime overlap
Problems to solve
At a high level, we aim to provide a solution that addresses several key customer requirements:
- Define and document an environment as code, stored in a repository for version control and collaboration
- Enable the browser-only, VS Code-based Web IDE to connect to a remote host and augment the experience by adding a full runtime environment
- Allow desktop IDEs to securely connect to the remote environments so developers can continue to use their preferred tooling
- Deliver an "IDE agnostic" architecture for flexibility (VS Code may be a first target, but we should be able to support JetBrains, vim, Theia, and others down the road)
- Flexibility to provision environments on multiple cloud platforms (AWS, GCP, Azure, etc.)
- Manage running, suspended, or pre-built environments in the GitLab UI
Why
As the Category:Remote Development development Spike has come to an end, we're at a crossroads with how we move forward technically.
Our initial plan was to begin building an integrated solution using Che as our Backend, allowing us a quicker time to market for a mature user experience when compared to building a homegrown solution ourselves.
Our choice has been challenged in three unique ways:
- We have noted that the Che Server was not written in Go but actually Java.
- We have been challenged on the assumption that our choice of Che versus the concept of using the current toolset that exists in GitLab already such as the Runners Fleet
- We have seen a viable PoC demo from the Server Runtime SEG showcasing a custom control plane that acts as a homegrown "Che server" which could provide an alternative path forward.
Technical Considerations
| Approach | Technologies | LOE | Pros | Cons |
|---|---|---|---|---|
| Che Backend | Go, Java | 3-6 Milestones | Offers most(if not all) of the requirements that we have, Community driven and with an EPL 2.0 License, Makes use of the operator pattern which abstracts burden from users, | Lack of Java Expertise, A reasonable amount of unknowns, Third party tool to be integrated, Possible lack of GitLab specific advantage |
| Custom Control Plane | Go | X-X Milestones | Greenfield project with no technical debt, add support for devfile and other configuration formats, tighter GitLab integration quicker, possibly easier to iterate on for smaller wins | Time to market for a fully functioning MVC will be longer than adopting an already scaffolded Backend |
| Runner-Based Approach | Go, Rails | X-X Milestones | It's possible that we have all of the needed ingredients necessary to build a Remote Development environment. | This approach has been explored already and was hit with many roadblocks. When revisited, it did not seem like we were any closer to removing the previous issues |
Server Runtime
Following the fantastic demo by the SEG, it seems there is enough overlap between the Server Runtime SEG and the Create:Editor team to form a working relationship to push forward collaboratively rather than working in isolation on different approaches to the same user requirements.
When compared to a similar situation inside Mobile DevOps, the Runner team is working on MacOS runners. There is a lot of overlap between these two projects and both teams require one another to be successful. In this situation, an ongoing relationship has been formed (using monthly sync meetings) so that they have been able to help each other out in different ways, and they have been able to bi-directionally influence product/technical choices.
| Solution Aspect | SEG | Remote Development with Che | Remote Development with Custom Control Plane |
|---|---|---|---|
| Greenfield | |||
| Licensing Considerations | |||
| Assumed Technical Debt | |||
| Go | |||
| Quick GitLab Integration | |||
| Quick time to market |
Outcome
The Create:Editor team will pursue Option 2 with the goal to leverage the GitLab Agent i.e. Kubernetes with KAS / GitLab Agent for Kubernetes. The Server Runtime SEG will continue to pursue a custom server with alternate networking and ingress solutions that supports provisioning bare VMs and doesn't require Kubernetes. There will be overlap in the two solutions but we will collaborate on limiting the duplicated effort and converging on a single, production-ready solution as one takes shape.