What are Remote Development Environments?

Github, Gitlab, Gitpod, Coder, JetBrains – everyone is talking about remote development and developing products they call Remote Development Environments (RDEs) / Cloud Development Environments. What’s behind all of this?

What are Remote Dev Environments?

First of all, a distinction must be made between remote development and remote development environments (RDEs).

Remote development is the basic idea that software developers can work on software projects in their home office or from anywhere in the world and together with people far away. This has been standard practice for many years, and software companies have been way ahead of other industries in this respect for many years.

However, the vast majority of software developers still work locally on their laptops. Source code is checked out locally, new code is written and debugged in the local IDE and the software to be developed is built and tested locally. When the developer is satisfied with her code changes, she commits them to the version control system – so that other developers can now check out the changed code at her place.

This means that the majority of software developers’ work still takes place “old school” on their own computers. Partly driven by the Corona pandemic, many companies are offering employees in various roles complete remote workstations and an ever-widening set of cloud tools. The personal computer is becoming less and less important. For many knowledge workers, some or even all of their work can now be done from any device.

Not so for software developers, who are still closely tied to their often expensive and powerful laptops. A lot of time and nerves are invested in setting up local development environments and keeping them running. Error handling is different for each local development environment and thus very time-consuming.

Where are the tools that also allow software developers to work completely remotely and detached from the local computer?

This is where RDEs come into play.

RDEs are remote environments in which developers have all the tools they need for their work. An RDE is therefore a tool that enables remote development and makes it easier. RDEs claim to make local development environments obsolete.

Remote development environment does not necessarily mean that these environments are available in the public cloud or as a SaaS product.

Remote simply means that the developers do not work locally on their laptop or computer, but connect to another environment. This can be in the employer’s data center, or in the employer’s private cloud, or a SaaS offering.

Various RDEs offer different options here.

Why RDEs?

Setting up a local development environment is the first hurdle developers have to overcome before they can contribute to a software project.

This usually very time-consuming task involves installing and setting up basic developer tools such as an editor or IDE and a version control system, as well as – and this is where it usually gets difficult – installing the software to be developed and all its dependencies.

Usually, a number of other steps are added (e.g., setting up WSL or Docker or connecting to CI/CD pipelines, etc.). The initial setup of a local development environment takes between two days and several weeks, depending on the complexity of the software project. Only then can a developer start writing code.

Once the local development environment is set up, developers report continuous effort to maintain it. In a survey of Gitlab users, 61% of the developers surveyed report spending time troubleshooting their local development environment at least once a month – 31% even at least once a week.

In addition to the time lost, which significantly reduces the productivity of software developers, the maintenance of local development environments also eats away at motivation: troubleshooting the local development environment is very unpopular.

Standardised remote development environments (RDEs) solve this problem. Developers create self-service development environments that allow them to go live in minutes. This also facilitates work on multiple projects, components and versions, as well as collaboration with external employees, since the source code and data remain securely and centrally managed on the RDEs and are not copied to local computers.

Read more:

5 Advantages of Remote Development Environmentes
Local Dev Env vs. RDE
Overview: Cloud Development Environments (Another term for RDEs)

Different RDE offerings differ in terms of the options they offer.

Whitepaper: Full list of CDE vendors (+ feature comparison table)

Get an in-depth look at how Cloud Development Environments work and compare all the vendors.

Get the whitepaper

What are RDEs capable of?

“For as long as it’s been around, the Web IDE has been held back by the lack of a runtime environment” – Eric Schurter, Senior Product Manager at Gitlab (https://youtu.be/apgU0y-u4A8)

The RDE offerings from Github, Gitlab, Gitpod and JetBrains are primarily aimed at providing Web IDEs with a runtime so that “full” IDE functionality is available via the browser. The table below gives an overview of what a local IDE usually offers in terms of functionality, compared to current Web IDEs and the RDE concept from different vendors.

However, there is still a large gap between what a Web IDE with an underlying runtime environment can do and what is possible with a local development environment.

Feature	Web IDE	Lokale IDE	Github, Gitlab, Gitpod, JetBrains RDEs	Local Development Environments (custom)	Cloudomation RDEs
Source Code Editor
Syntax Highlighting
Autocomplete
Source Control (integration)
Build: interpreting or compiling and executing code	-
Debugging	-
Unit tests	-	-	-
Running full application	-	-	-
Integration tests	-	-	-
Packaging	-	-	-	-	-
Deployment	-	-	-	-	-

Cloudomation RDE Software

Our aim is to provide RDEs that are fully equivalent to local development environments. The primary aim is to operate complex applications such as large monoliths, non-containerized software or software with multiple components in the RDE.

Ease of use for developers is paramount: full access and full adaptability of the RDEs for the developers as well as working that is almost indistinguishable from local development. The central aspect here is the possibility to use any local editor, a local or web IDE, and to enable integration with the Cloudomation RDE in several ways: via a mounted file share with sources for local editors / IDEs or via ssh for Web/remote IDEs.

Build from not yet committed intermediate statuses, reuse of already existing local build tools (e.g. code not minimized) and comfortable inspection of logs complete the picture.

The particular strength of Cloudomation lies in the extensive automation and integration functionality that is available in the RDEs. As a Python-based automation platform, Cloudomation can automate many more steps in the same system beyond “pure” infrastructure automation of the RDE – such as automated integration tests on the RDE.

Conclusion

RDEs are remote development environments that are intended to replace local development environments.

Since a few years there are first software solutions that want to support the deployment of RDEs – but many of them are currently still very limited and offer somewhat less functionality than a local IDE.

But it takes more than an IDE, it takes a runtime environment for the applications to be developed and automation tools to enable local build there. With this extended functionality, a remote IDE becomes an RDE. Only then do developers have the tools at hand to become truly productive with RDEs.

With Cloudomation DevStack we provide remote development environments to operate complex applications in the RDE. And the best thing is: you can still use your own IDE and favourite tools. Check it out!