Cloud Development Environments (CDEs) are a new product category. Many new vendors appeared on the market in the last two years, and each one has a slightly different idea of what a CDE should look like. In this article, I will explain the most common architecture and features of CDEs, and what makes Cloudomation DevStack special.
Standard CDE architecture
The most common CDE architecture works as follows:
- A developer has an ssh capable IDE client installed on their laptop (e.g. VS Code or IntelliJ)
- The IDE client connects to the IDE backend on the CDE
- The CDE is either a container (most common) or a (micro-)VM
- The CDE contains:
- IDE backend
- Source code repository
- Required language runtimes and SDKs
- Other tools as required, e.g. linters or debuggers
- Typically, the software that the developer works on will also have to be deployed to the CDE. However there are large differences on how this works with different CDE products.
- Many CDEs also work with in-browser IDEs, removing any dependency from the device that the developer works from.
Get an in-depth look at how Cloud Development Environments work and compare all the vendors.
Get the whitepaperDevStack architecture
The main goal of DevStack is to make working with a CDE feel the same as working locally. The switch to using a CDE should be frictionless, requiring little to no changes to the habits and preferences of developers. In order to do this, DevStack differs from most other CDE vendors in several important aspects:
Choice of any IDE
Due to the ability to cache source code on the developer’s laptop through a shared drive, developers can use any IDE they like. There is no requirement to use an ssh-capable or browser-based IDE – though those can be used as well, if that is the developer’s preference.
Caching of files in shared drive
Often, developers want to or need to inspect files that their software produces or interacts with – reports, logs, or other documents or objects. With most CDEs, this is cumbersome since developers often have no direct access to the CDE, or if they do have access, it is only ssh access where they can work with remote files in the terminal.
Developers are left with either inspecting files in the terminal, which is cumbersome and not possible for some types of files, or they copy files to their local workstations, which is again cumbersome and slow, especially if changes in the files need to be checked iteratively.
With DevStack, developers can choose file paths that they can mount locally, so that files are automatically synchronized with the CDE.
Access to CDE
In addition, developers have full access to the CDE via ssh, enabling them to work with the software they develop through the terminal in the same way they would if the software were running locally.
CDE as VM
As the core unit of the CDE, DevStack provides full VMs. Most other CDE products use containers as CDEs, sometimes deploying individual VMs for each development container to ensure full separation of CDEs, but not allowing access to the VM. Also, developer tooling is deployed to the development container, and not the VM. With DevStack, developer tooling is deployed directly to the VM, so the distance between the developer and the application they develop is minimal.
In addition, having a full VM as CDE makes it possible to deploy multi-component, heavy-duty software to the CDE, which is not possible within a single development container.
Summary
Even though it is a new product category, a common architecture is emerging that most CDE products follow. DevStack differentiates itself by extending this standard architecture in a way that limits friction when moving from local to cloud based development, enabling developers to continue working in almost the same way.
Subscribe to the Cloudomation newsletter
Become a Cloudomation Insider. Always receive new news on “Remote Development Environments” and “DevOps” at the end of the month.
