How Developers Can Survive the Last Mile with CodeReady Workspaces – InApps 2022

Red Hat sponsored this post.

The promise of cloud-based software development comes with a large toolkit. It’s a bit like a kit car or a new house-in-a-box: you’ve got all the pieces there in front of you, you just have to assemble them properly, put them in place and get inside.

As a way to piece together this explosion of available open source tools into simple and coherent single interface for cloud native deployments, the Eclipse Foundation offers the Eclipse Che integrated development environment (IDE).

Today’s often desperate need for Eclipse Che can be traced back to the evolution of open source tools during the past 10 years. Not only have these tools been evolving, but in many cases, they have been outright created from scratch. That’s posed a bit of a problem for those out on the cutting edge of scalable microservices as the stable infrastructure components of old gave way to a hodgepodge of brand new open source and commercial products and tools.

Inside each cloud provider, a host of tools can address CI/CD, testing, monitoring, backing up and recovery problems. Outside of those providers, the cloud native community has been hard at work cranking out new tooling from Prometheus, Knative, Envoy and Fluentd, to Kubenetes itself and the expanding ecosystem of Kubernetes Operators.

Within all of those projects, cloud-based services and desktop utilities is one major gap, however: the last mile of software development is the IDE. And despite the wealth of development projects inside the community and Cloud Native Computing Foundation, it is indeed the Eclipse Foundation, as mentioned above, that has taken on this problem with a focus on the new cloud development landscape.

Eclipse Che: A Cloud-Based IDE

Perhaps it shouldn’t be surprising that the nonprofit foundation created to support the Eclipse IDE has long been working on a cloud-based IDE: Eclipse Che. The Che project began life as a part of Codenvy, a startup acquired by Red Hat in 2017.

The team behind Codenvy’s commercial browser-based IDE spun off the Che Project to the Eclipse Foundation a few years before the acquisition. Upon acquisition, Red Hat contributed the previously proprietary code from Codenvy to the Eclipse Che project.

Now Red Hat offers a free subscription and global support for Red Hat’s CodeReady Workspaces, which is based on Eclipse Che. This, plus adoption by many large companies, has injected a burst of energy into Eclipse Che from those looking for cloud-based development tools to help their teams go faster.

While the traditional IDE market has been focused on the niche desires of specific programming language users, Eclipse Che and Red Hat CodeReady Workspaces have taken the approach of offering a more generic GUI-based workspace, with the actual programming language being a second tier concern. Nowhere is this more evident than through the usage of the Language Server Protocol (LSP).

The LSP was designed in conjunction with Microsoft and others to allow the code completion and other language-specific code rendering information to be distributed to IDEs as a service, rather than having those features built into the IDE itself.

This allows the language support within Che and CodeReady Workspaces to be updated at the same pace as the language itself, rather than at the pace of the IDE. That’s especially important for a language like JavaScript, where the rate of change is increasing.

A Kubernetes IDE Via Operators

This also means that Che and CodeReady Workspaces are not meant to be replacements for everyday IDEs, like IntelliJ, emacs or vi. But it’s only with the advent of Kubernetes Operators that the true power of a cloud-based IDE can be brought to bear on container-based clusters.

That’s because Operators allow developers to provision their own systems and services on demand, with preconfigured access controls and governance put in place by administrators. Therefore, developers looking to quickly open up a misbehaving service and change a single variable within the cluster can now quickly do so without having to tie their own laptop or desktop environment into the tangled web of security and service authorization that exists within a Kubernetes cluster.

Mario Loriedo, software engineer at Red Hat, said the Che team is focused on making the IDE work more seamlessly in a Kubernetes-based environment through the Operator. He said the team is: “Working on making the Operator more intelligent. We’re adding some Prometheus endpoints to get feedback from the Language Servers. If a user developing doesn’t get suggestions right away, it’s because the server is slow, or because it requires more memory. This is information that can be used by the Operator to fix the memory problem or disk space problem and redeploy the environment.”

Elsewhere, the team is also working to integrate with Kubernetes and Linux containers to make the revise and redeploy cycle easier. “In the time of Codenvy, if you wanted to develop your app inside the Che environment, you had to somehow patch the container of your app. Then you had to add the development tools to the production container,” Loriedo said. “With this new version, you can take the production containers and bring them inside Che. We are running the common tooling as sidecars. The Language Server is running as a sidecar, and you can turn it on or off if you need it. You don’t need to reveal your application container. That brings your production container inside Che, and creates a new instance inside your IDE.”

Feature image via Pixabay.

The Cloud Native Computing Foundation is a sponsor of InApps.