Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[che-dev] Workspace.Next

As you may know we have been discussing and doing some early ground work around workspaces for a while. I think we are now at a stage where we need to describe our goal with workspaces. So now I will start by a description of what I (creatively) call Workspace.Next. Hopefully this will lead to some discussion and eventually our technical solutions.

Overview

Kubernetes/Openshift (or similar orchestration software) automates the provisioning of applications and services within an environment. However, getting started with these are not easy because you still need to setup the environment initially. At the moment, Che stacks and workspaces replicates this environment setup at least for the parts that are subject to development. This means that initial getting started setup for the development environment needs to be expressed as a Che specific way that is different than the how the orchestration software expresses the environment. This further hinders the getting started experience for Che.

Workspaces do not drive from stacks

Che workspace definitions should start from the environment definition, as defined for the orchestration software, and filter/replace part of the definition with workspaces. For instance, When developing a service for an application that has 5 microservices and 2 databases, a developer should be able to replace a microservice and the database that this service uses on its developer environment but still keep the remaining dependencies intact. All of these should be selections that are based on the definition of the production environment.

We are already starting the work to merge chefile and factory json. Without stacks this new chefile should be our main metadata for creating a workspace. This file as it can live on the code repository can be shared, forked, merged, branched much easier than stacks. Also since it will be a simple file, code generators can easily create a workspace for a new project while they generate the code. Furthermore we can repurpose and enhance some of our assets from dashboard to create a graphical/form editor for chefiles. When combined with factories creating and starting a workspace should become as easy as entering the url to your repository.

Better Dev Modding

Since our goal is to be able to take any container and use that for our workspace within the security limitations of kubernetes or similar orchestration software, our current delivery via installers do not service well with security restrictions. We also would like to make it easier for anyone to deliver workspace agents and delivery of agents as containers just looks natural. There is already some ongoing work with sidecars around this.

Multiple dev machines

At the moment Che conquered the development of a single service on a single container. It is time to expand and we need to enhance our workspace definitions so that we can develop 2 or more services that are deployed on different containers within a single workspace (or IDE window).

Thanks,
Gorkem


Back to the top