Comparison of Development Environments
There’s a range of architectures for hosting and managing development environments. The conventional way is to host everything on each developer’s workstation, including the IDE, build tools, package management, and so on. More sophisticated development environments give greater control over environments for the whole dev team.
Intro
As a development effort grows from a single developer, to a team, to an organization of several teams, so do the demands on development environments. In this article, let’s look at the range of architectures for environments that can support the evolution of software development in an organization. We’ll start with the simplest dev environment and finish with the most sophisticated:
- The IDE and the development environment: The IDE isn’t the whole picture
- Pure local development environment: Hosting everything on the workstation
- Virtual Desktop Infrastructure: Putting the local environment in VDI
- Dev container: Host the dev environment in a container
- Cloud development environment: Run dev environments in the cloud along with tools to provision, manage, and monitor them
The IDE and the development environment
The integrated development environment (IDE) is the developer’s portal into the development environment. It’s the place where the developer navigates and edits code, starts builds, and maybe runs a debugger. Because it runs locally, typically as a native app, it’s responsive and the developer can customize the IDE for their own needs with preferences and plugins.
But the IDE isn’t the whole picture. It’s just one component in the development environment. There are many other components that the IDE has little or no control over except to start, stop, and view progress.
This leads us to the simplest development environment, which is purely local.
Pure local development environment
You’ve already seen this setup in What is a Cloud Development Environment. In a purely local dev environment, the IDE and the rest of the dev environment run locally on the developer’s workstation.
Besides the IDE, the other components in the environment are the tools, code, package management, and so on. The IDE isn’t meant to install these components, administer them, or specify how they integrate. The IDE’s goal is to ease day-to-day coding workflow, not manage the environment as a whole.
In other words, the IDE expects a complete dev environment that’s already installed, configured, and ready to use. And that’s what the developer provides with their workstation: a place to host a working development environment for the IDE.
When to use it
- For the single developer or a small dev team, a purely local environment works great.
- Low cost to set up on a single or a few workstations.
- The workstation has enough compute and storage capacity to adequately store, build, and run the project.
You’ve outgrown it when
- Differences creep in between environments among the team’s workstations.
- Technical onboarding is longer because the environment’s complexity has increased.
- Build times are longer despite workstation upgrades.
- There are more developers than there are instances of expensive hardware like GPUs.
Virtual Desktop Infrastructure
Your team has grown and so has your development environment. It's time to get a handle on growing complexity and the rising cost of workstation upgrades. A common solution is to transplant the entire dev environment to virtual desktop infrastructure (VDI) in the cloud.
The developer uses a remote desktop client, like RDP or VNC, on their workstation to log into a remote desktop instance. This immediately gives the development team more consistency by letting them create a single virtual desktop image that can be spun up for each developer. And it opens the opportunity to reduce contention for expensive hardware, since the cloud has practically limitless compute and storage resources.
The organization can reduce cloud spend by specifying ephemeral VMs, but this reduces customizability for the developer. And there’s the possibility that developer experience will suffer from network latency between the remote desktop client and the cloud, especially for developers far from the geographical location of the VDI.
When to use it
- Small and medium-sized teams with development environments that are small enough to fit on a single (virtual) machine.
- Cloud costs are less than purchasing and upgrading workstations.
When you’ve outgrown it
- The development environment has grown in size or complexity where it’s no longer practical to put in a single VM image.
- Spending is high for the cloud compute, block storage, and software licensing to run virtual desktops.
- Geographically remote developers suffer from too much network latency.
Dev containers
The organization has grown into a few teams and they’ve outgrown the virtual desktops, or they want to improve dev experience and lower costs. A dev container can handle these challenges.
Development containers are an open standard and are well-supported by many dev tools and hosting services.
Notice that the developer gets to work with a local IDE again while the rest of the environment is in a container. So unlike virtual desktops, the dev container setup restores customizability and responsiveness to the developer experience.
Being a container, it provides a proven, reliable, industry-standard way to precisely specify the development environment once then deploy it consistently as many times as needed. The cost of provisioning containers can be cheaper than virtual desktops, since containers can run on less expensive services.
The organization’s platform engineering team can manage the dev environments with the same container infrastructure that they’re probably using already for other application deployments. They can also manage expensive hardware more efficiently, like adding more cores to the computing instance to reduce build times.
When to use it
- The costs of provisioning virtual desktops, especially persistent VMs, is prohibitive
- Give platform teams more flexibility in hosting the dev environment
When you’ve outgrown it
- Managing containers for multiple teams and projects gets complicated
- Security requirements add complication
- Limited customizability in the containerized environment for developers
- Dev environment hosting services lock you into their platform
- Some projects can’t be practically encapsulated in a container, like legacy projects
Cloud development environment (CDE) The previous architectures use general-purpose platforms to host dev environments. They aren’t specialized for software development, so administering them is left to developers or the platform engineering team.
Now imagine a platform that solves all the problems of the previous architectures with added functionality that’s dedicated to managing, provisioning, and monitoring dev environments. That’s what a cloud development environment (CDE) platform does. We’ve already covered the advantages of CDEs in Benefits of cloud-based development platforms, but here’s a recap for this article.
Notice a few things in this architecture:
- The CDE’s control plane consolidates the management, monitoring, access control, and audit logging of development environments.
- The CDE doesn’t dictate how the developer interacts with their environment. For example, they can use an IDE, web browser, or secure shell.
- The CDE template can add extra convenience when starting a workspace, like automatically pulling from repos and updating dependencies.
There’s an important distinction between a CDE workspace and a dev environment. The CDE workspace encapsulates the dev environment but doesn’t impose any constraints on how the environment’s components are hosted and run. They can all run in the cloud, on-premises, in a container, a cluster, a VM, or whatever combination the project needs.
Then there’s scale. Spinning up and tearing down dozens of environments is straightforward enough. A CDE is capable of managing and monitoring hundreds, even thousands, of dev environments.
When to use it
- Need to handle the complexities driven by security, legacy, or variability in dev environments.
- Relieves the platform team from tedious, error-prone tasks to manage complex or large-scale dev infrastructure.
Conclusion
A software development team today has many choices to set up their development environment. Just an IDE and a few configuration files on a workstation is good enough for a lone developer or small team. As projects and their dev teams grow, there are better ways to handle the complexities in setting up and managing dev environments.
Not sure what a CDE is? Check out What is a Cloud Development Environment.
Subscribe to our Newsletter
Want to stay up to date on all things Coder? Subscribe to our monthly newsletter and be the first to know when we release new things!
