If you worked with developers before, there is a good chance that you’ve encountered the “It works on my machine” problem.

A lot of teams struggle with onboarding developers. There are a couple of reasons for that:

1. Incompatible dependencies
2. Unsupported libraries
3. OS differences, etc.

It’s inevitable that at some point, you find yourself with a dependency that just can’t seem to install and set up. You ask a colleague for help but you hear the feared phrase: “But it works on my computer” and you’re left to fight the battle on your own.

Setting up complex projects can take hours, days, or maybe even weeks, leading to frustration and dissatisfaction from the employee.

Research made by the Brandon Hall Group shows that a great onboarding experience can improve employee retention by, a staggering, 82%. That strong influence comes from the fact that no one wants to spend more time troubleshooting than actually coding.

Okay, so now that we laid out the problem, let’s see how ephemeral cloud-based development environments can take your dev experience to the next level.

Ephemeral environments are no stranger to the DevOps world. Sometimes referred to as infrastructure-as-code, they ensure repeatable and consistent environments without configuration drift. In modern CI workflows it is common to have a fully functional environment for each pull request / branch where you try the new features or run functional tests. After the PR is merged, the environment is scrapped to free up resources for others.  The same can be achieved for development environments.

Traditionally the configuration requirements are described in the README.md file, and the developer is expected to set up their local environment to match the configuration requirements. And as the project evolves, the developer needs to update their local environment to reflect configuration changes.

Instead of describing configuration dependencies in the README.md file, the configuration is defined in an explicit format and is a part of the source code. Every dependency needed to start and develop the project is included in the configuration file, as shown in the figure on the left. Each time a developer continues working on the project,  a fresh developer environment is created and configured from scratch, ensuring that the project can be run and all tools needed for development are available.

As you can see, with this simple configuration, you will get a code-ready environment that includes a runtime, database and Redis cache store, and each environment is guaranteed to be set up in the same way.

There are no more “But it works on my machine” excuses.

This is what we call an ephemeral development environment.

Powered by containers

As said, ephemeral environments are commonly used in the DevOps world. What made this possible is Container technology. Container usage exploded in the last decade, most notably because of the Docker project.

Containers enable an IT team to abstract application code from the underlying infrastructure, simplifying version management and enabling portability across various deployment environments.

Container orchestration systems like Kubernetes made enterprise-grade scaling of containerized environments affordable to organizations of any size.

The concept has brought a revolution to the CI/CD process and propelled the DevOps profession mainstream.

There is no reason not to embrace the same benefits in your development workflow. We can use these ephemeral environments as development environments or workspaces. They can range from very simple ones with just one container with one programming language and tooling to complex environments with databases, memory stores, and other services that mimic the real production environment.

Don’t compromise on performance

Laptops, of course, have CPU and memory constraints, and running very complex projects can become very intensive or even impossible. Companies sometimes remedy this by having mocked services or having developers boot only parts of the infrastructure. The ability to define basically limitless CPU and memory per service allows everyone to work with the entire project without ever having to worry if their machine can handle it.

How to code inside the environment?

Now that we’ve learned how to set up these ephemeral environments, how do you actually code inside them?

There are two approaches here:

1. Connect your local IDE, through SSH, to your runtime service. An example of that would be connecting VS Code with the Remote Explorer extension and working just as you would on any other project.
2. Install a browser-based IDE into the runtime service and expose your environment network to allow connections through a domain or IP address. A great example of this is the Open Source Theia IDE which is a great browser IDE with all the tools needed to code just as you would locally.

Increase productivity without restricting choice

To sum up what this all means for developers and companies.

Developers will see an increase in productivity, be ready to code from day one, and remove the “It works on my machine” from their vocabularies.

Companies can expect new developers to be more satisfied with the onboarding process and have a better retention rate. Also, you can allow developers to truly choose any computers they want to work on, without restricting their choice to pre-setup machines.