Red Hat will soon release a higher-performing, richer version of the Red Hat CodeReady Workspaces development platform, along with a name change to Red Hat OpenShift Dev Spaces. The platform has been significantly upgraded by moving to a Kubernetes Operator. This article explains the major changes in this upgrade and their effects on administrators and users.
The team worked on this version for over a year and introduced the new platform as a tech preview after CodeReady Workspaces 2.10. The official name of this release is Red Hat OpenShift Dev Spaces 3.0.
Changes to the workspace engine
The core of CodeReady Workspaces used to be a Java REST web service named che-server, which provisioned pods and other objects to run development environments on Red Hat OpenShift. With OpenShift Dev Spaces 3.0, we are introducing a new OpenShift Operator to replace the che-server: the DevWorkspace Operator (Figure 1). This is a big architectural change whose benefits we'll summarize in the following sections.
Scalability and high availability
The che-server could not scale horizontally: it wasn't possible to run two instances concurrently. The new engine is a Kubernetes controller, so it runs behind the kube-apiserver that is designed to scale horizontally. The data is persisted in an etcd key-value store that is designed to be highly available.
A universal API
Workspaces are Kubernetes objects. Useful traits of this architecture include:
- Kubernetes clients such as kubectl or the OpenShift console can manage them.
- They are secured via Kubernetes RBAC.
- They can be validated and protected by admission webhooks.
- The devfile specification is automatically generated from the API.
A simpler design
The new workspace engine has a single responsibility, which is to manage workspace resources. The engine is decoupled from the developer's IDE and the server-side components of the OpenShift Dev Spaces service. Communication between components happens asynchronously using ConfigMaps and Secrets rather than a REST API.
An opportunity for refactoring
The new engine has been written from scratch, and we took the opportunity to address some of the main issues reported by our users:
- Simpler configuration for the administrator
- No hard dependency on Red Hat's single sign-on technology
- Simpler network model and TLS certificate management with one unique gateway
The switch to the DevWorkspace Operator introduces changes for existing users and administrators of CodeReady Workspaces. Here is a summary.
There is a new server-side component: the gateway (powered by the open source reverse proxy Traefik) that handles users' connection to the IDEs. Several simplifications have been made to administration, along with new options:
- User workspaces can be managed with the
occommand-line interface (CLI) or via the OpenShift console.
- CRW doesn't require Red Hat's SSO anymore and uses OpenShift OAuth for authentication.
- Deployment is simpler because there are fewer configuration options. For instance, the namespace strategy and the exposure strategy are set to "per-user" and "single-host" respectively, as we have observed that users want those settings.
- The operator installation mode is "all namespaces."
Our enhancements to the user experience include:
- We now support version 2 of the devfile spec, which has some significant improvements in regard to parents and events. Version 1 devfiles also continue to be supported.
- Devfiles are IDE agnostic and don't include plug-in definitions anymore. IDE-specific configurations are managed in separate files as extensions.json in Visual Studio Code.
- We have added tech preview support for VisualStudio Code as an IDE (in addition to Eclipse Theia and JetBrains IDEs).
- Workspaces load faster, with fewer containers per workspace.
How to get OpenShift Dev Spaces
We plan to release Red Hat OpenShift Dev Spaces in the coming months. It will support OpenShift 4.10. Installation can be done through the usual channels, via the OperatorHub or the command line.
Existing Red Hat CodeReady Workspaces customers won't be upgraded automatically to OpenShift Dev Spaces but will need to follow a manual procedure to upgrade their instance.
To learn more, check out the following resource:
Kudos to the whole Che team at Red Hat that worked hard on this challenging pivot.Last updated: May 3, 2022