5 Advantages of Remote Development Environments

Software developers usually work in their local development environment. However, because each local development environment is different, very individual problems arise that are time-consuming and difficult to solve. With Remote Development Environments, the time developers spend maintaining their local development environment is reduced to zero. What other advantages are there?

TOC

Remote Development Environment - What does that actually mean?

In a nutshell: Remote Development Environments (RDEs) are remote development environments that are meant to replace local environments.

In order to make this possible, all tools necessary for software development must be available in RDEs – including the application to be developed, which can be operated in the RDE and to which developers have full access.

Caution: Other RDE providers usually have a much reduced understanding and only offer a subset of functionality, such as a browser-based IDE or remote-capable IDE with a remotely running backend. These offerings generally do not support running the full application being developed in the RDE and also significantly less access to and less tooling in RDEs than is available in Cloudomation RDEs. Also, the term Cloud Development Environments is often used as a synonym for RDEs.

We have described all the details in the article “What are Remote Development Environments“.

5 Advantages of Remote Development Environments

#1 Time saving

Elijah Bate of theoptimisedweb.com writes: “Setting up new development environments or trying to update the local machine for different projects when the configurations are different really sucks. The time other developers and I have spent debugging Nodejs version issues, installing and uninstalling different SDKs, and finding and setting up environment variables and secrets is just insane.”

Elijah Bate is not alone in this problem. Setting up and maintaining the personal development environment is perceived as one of the most unpleasant tasks for developers.

Several hours per month are often spent troubleshooting. As each local development environment is slightly different from that of colleagues, each developer has to deal with their own unique problems.

In addition to the IDE and source control, which is usually set up quickly, many dependencies have to be set up and kept up to date, tools for local builds have to be made to work and, most challenging of all, the software to be developed has to be run locally. This often involves the use of tools and scripts developed within the company, which are error-prone and difficult to use.

RDEs solve this problem. The time for problem solving drops to zero. Different versions of the software to be developed can easily be worked on in parallel, in separate RDEs. Changing devices is also easier. In addition, software development can take place on almost all end devices, even if they are not very powerful.

#2 Standardisation

One problem with local development environments is that each is different.

Even with strict device and software guidelines, the possible disruptive factors can be limited, but never completely eliminated. Individual problems with local development environments still occur.

This is particularly frustrating when you consider how time-consuming it is to develop and continuously enforce standardisation guidelines and how much resistance and frustration this often creates among developers who have to give up tools they hold dear and instead work with software they don’t like.

What would it be like if developers had completely standardised development environments at their disposal at the push of a button, which are created anew every time and correspond 100% exactly to the guidelines?

And at the same time, developers can be given a completely free hand as to what they use locally for the operating system, browser or other tools? That is exactly what RDEs make possible.

The biggest advantage: Standardised RDEs are naturally defined to be as close as possible to the production environment of the software being developed.

Due to the limitations of local environments vs. the server environment of RDEs, RDEs become much closer to the production environment (e.g. running a Kubernetes cluster on an RDE also suddenly becomes feasible, which can lead to a lot of headaches locally). This also reduces the “works on my machine” problem.

And at the same time with a significantly higher developer experience – i.e. a more pleasant and enjoyable way of working for developers.

#3 Outsourcing computing-intensive resources

Joel Spolsky writes: “First-class development teams do not torment their programmers. Even small frustrations caused by using inadequate tools add up and make programmers grumpy and unhappy. And a grumpy programmer is an unproductive programmer.”

Developing software means performing computationally intensive work, such as compiling, testing and running the software.

This means: frustration for developers when RAM almost goes up in flames because of a tool and they have to wait for tests etc. to be completed. And: frustration for management due to the costs of providing the appropriate equipment.

Because RDEs take over performance-intensive processes and run on a remote server, the choice of work device can be cheaper and reduce costs for companies.

Developers nevertheless have all – and even more – resources available in the RDEs that they need for comfortable development work.

Due to the scalability of RDEs, they are usually even significantly more performant than even very powerful laptops.

The times are over when developers wait forever for the local build to be finished (because the laptop next to it can’t do anything and the build still takes a long time).

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

#4 Productivity

All developers know it: Changing branches in the local development environment or even going back to an old version of the software to fix or check a bug is tedious.

Everything must fit together: All dependencies must be present in the correct version, all components of the software must work together – and who knows exactly which versions were compatible again?

After the bug fix, the whole thing goes back into reverse: re-pull your own latest feature branch, update dependencies, and hope that the customer who is still using the old version doesn’t find another bug so soon. All of which have already been fixed in the new version anyway.

Solution? Sure, force all customers to always use the latest version. Unfortunately, this is often not possible in reality.

And even without customer bug fixes in old versions, changing branches is often necessary, it is part of normal development work.

The solution cannot therefore be to make branch switching obsolete. A nicer solution: RDEs.

These are available ready-made in all required versions. If required, RDEs can be created not only for major versions, but even for specific commit hashes of individual branches. Each developer can run several of them in parallel. This suddenly makes working in different branches child’s play.

This not only increases productivity and reduces frustration, but also leads to significantly better support from customers. After all, if it’s easy, people are much more likely to help.

#5 Security of source code and data

In times of remote work, supervisors sometimes don’t know exactly where their developers are.

Collaboration with freelancers around the world is becoming more and more normal. And with that, the issue of source code and data security is becoming more urgent.

What happens if the laptop is left behind in a taxi in Delhi? Or what happens if the colleagues in the USA don’t have their own lockable office in the co-working space, but simply leave their work equipment open overnight?

Once the end device is lost, access to remote resources can be blocked – but what is on the laptop is lost forever.

A headache category all its own: access to personal data necessary for testing the software. What is the best way to handle this, legally and also practically, when one’s team is scattered all over the world?

Measures such as encrypting hard disks, guidelines for using trusted networks, disabling USB ports, working via VPNs – many possible solutions exist. All of them are problematic because each one involves significant effort, is difficult to enforce and yet only partially solves the problem. What to do?

You can guess the answer: Cloudomation RDEs can be fully air-gapped (Glossary: What is an air gap?) so that source code never ends up locally on the developers’ computers. Test data can be used in RDEs, but shielded so that developers do not have direct access.

For developers, working in the RDE is comfortable, so there are no incentives for misuse, which often takes place in the service of productivity and with the best intentions. And since source code and data are never stored locally, the risk of loss or theft of the end device is zero.

Conclusion

RDEs help to save valuable time: In setting up the development environment and subsequently in troubleshooting.
RDEs lead to a standardisation of development environments. This makes troubleshooting easier, company guidelines are 100% fulfilled and developers can still use their favourite tools. They also get as close as possible to the production environment.
Computing-intensive resources are outsourced. Development work can thus take place on almost all devices.
Productivity increases because when a branch is changed, only the RDE set up for it needs to be called up.
Security: With RDEs, the source code never ends up on the computer.
RDEs help to solve current challenges in software development.