Articles Best Practices News Remote Development

From VDI to CDEs: Solving Remote Development Challenges

Virtual Desktop Infrastructure (VDI) has been a popular solution for remote development, but it is not without challenges. At JetBrains, we’ve recently seen growing interest in Cloud Development Environments (CDEs) as an alternative.

To understand why many are thinking about this shift, we contacted our customers and uncovered the key reasons behind the trend. In this blog post, we’ll share what we learned.

TL;DR: VDIs can be helpful for specific use cases, but CDEs are a better choice for software development.

What are VDIs and CDEs?

Virtual Desktop Infrastructure (VDI) is a technology that manages and delivers remote machines, typically virtual ones, to end-users. Users interact with these machines via protocols like RDP, PCoIP, or HDX, which stream the desktop interface to the user’s device. So, technically, VDI uses video streaming to provide a full desktop experience but in a remote environment. This means the remote machine can be used for any purpose, like web browsing, video conferencing, software development, etc.

Companies use solutions like Citrix Virtual Apps and Desktops, VMware Horizon, and others to manage VDI environments (VDIs).

Cloud Development Environments (CDEs) are a newer concept purpose-built for software development. Usually, a CDE is a Docker container or a virtual machine created from a template that specifies the image, repository, environment variables, secrets, and more.

Unlike VDIs, CDEs are designed to be ephemeral, meaning they can be created, used, and destroyed quickly. A developer can create multiple CDEs for different tasks with only the IDE backend running remotely. Communication with the CDE happens via a local client over an efficient JetBrains Remote Development Protocol (in the case of JetBrains IDEs) developed specifically for that case. It makes mouse movement, typing, and the overall experience with the code editor much more pleasant.

To manage CDEs, you need a CDE orchestration solution like JetBrains CodeCanvas.

Why companies use VDIs and why they’re looking to switch to CDEs

During our interviews, we identified the most significant reasons companies use VDIs and why they

aren’t always the best choice for software development. We won’t discuss all the pros and cons of VDIs and CDEs, but we’ll focus on the most common pain points.

1. Security

Security is, without question, the primary motivator for companies to adopt VDIs. While other factors are often cited as benefits of remote development, they are rarely the primary drivers. VDIs provide an out-of-the-box solution for high security requirements.

However, while CDEs require more effort to set up (e.g. integrating with third-party tools), they offer more flexibility and cloud-native security features.

Why do companies choose VDIs?

VDIs excel in security:

• Centralized access control: VDIs provide centralized, user-level access control. Typically integrated with systems like Active Directory, user accounts are managed centrally, and their permissions define what resources they can access on their assigned VDI machines. For example, if a user has the necessary credentials to clone a repository, they can do so directly from their VDI environment. The VDI serves as a general-purpose entry point to the organization’s infrastructure – the fact that a user creates a VDI machine doesn’t mean they have started working on a specific project.
• Preventing code leaks: No source code is stored on local machines, and copying code via the clipboard, file transfer, and screen capture can be disabled.
• Secure access to internal resources: VDI environments typically operate within the company’s network, granting access to internal resources like databases or internal services without exposing them to the internet.

What can CDEs offer?

CDEs can match VDIs in security and even offer additional advantages, but they might require more effort:

• Centralized access control: CDEs also offer centralized access control, often integrated with external providers like Active Directory. However, CDEs add another layer of control through template-based access. For example, in CodeCanvas, a CDE template defines everything a developer needs for a project: the Git repository, required secrets, environment variables, etc.
  The resulting CDE contains only the resources necessary for a specific project, contrasting with a VDI machine, which typically grants general access. For administrators, this provides additional visibility into developer activity, making it clear which developers are working on specific projects, when they started, and how long they’ve been working.

• Prevent code leaks: No code is stored on the local machine. Clipboard restrictions can be implemented at the IDE level, but additional protections, such as file transfer and screen capture restrictions, may require third-party tools.
• Secure access to internal resources: As CDEs are deployed in the company’s cloud, it’s easy to organize secure access to internal cloud resources. For example, CodeCanvas lets you link Kubernetes service accounts to specific templates, granting developers automatic access to required cloud resources without manual configurations or permissions.

2. Environment standardization

The second most common reason for adopting remote development and VDIs is the desire to standardize environments across teams. While VDIs offer some level of standardization, CDEs take it to the next level.

Why do companies choose VDI?

VDIs offer some standardization:

• Persistent environments and configuration drift: These are essentially personal remote machines tied to individual users. Standardization is achieved by setting up a golden image – a pre-configured baseline environment. However, users treat these environments as personal machines over time, installing additional software or making changes that lead to configuration drift and works-on-my-machine issues. 
• Non-persistent environments and state loss: These reset to the golden image state after each session. This ensures consistency, but fails in software development since all uncommitted changes are lost when the session ends.
• Hybrid environments: Some VDIs offer hybrid approaches to preserving state, such as detaching and reattaching user disks, but these are complex to set up and maintain.

What can CDEs offer?

CDEs offer much better standardization:

• Ephemeral environments: CDEs aren’t user-specific but project-specific. They are ephemeral – they’re created when needed and discarded after use. Standardization is achieved via templates that define the base image with tools, a Git repository, environment variables, etc. In CodeCanvas, standardization goes even further:
  • You can pre-configure the dev environment’s IDE with plugins and personal settings.
  • You can use the warm-up feature – CodeCanvas pre-creates IDE indexes, builds the project, fetches dependencies, and stores the result as a single volume snapshot. This snapshot is then distributed across all CDEs based on the same template. If you schedule the warm-up task overnight, in the morning, every new dev environment will be ready to go with prebuilt artifacts and a fully indexed IDE.
• No configuration drift: Since CDEs are ephemeral and recreated from templates for each task, developers can’t make persistent changes that deviate from the standard.
• Preserved state: CDEs can be paused and resumed, preserving the state of the environment, including uncommitted changes. In solutions like CodeCanvas, storage is unmounted when the environment is stopped and remounted when it is resumed.

3. Developer experience

The developer experience is an unavoidable topic in any discussion about remote development. We haven’t met a customer who was satisfied with VDIs in this regard. One of the core issues is that VDIs were never designed for software development.

What can VDIs offer?

VDIs offer traditional local machine workflows. VDIs were originally designed to replicate traditional desktops in a remote environment, focusing on general user applications rather than specific software development needs.

• Latency and performance issues: In every single interview we conducted, this was the top complaint from VDI users. VDIs rely on protocols like RDP, PCoIP, or HDX to stream the entire desktop interface to the user’s device. This approach highly depends on network quality and struggles to maintain the responsiveness needed for software development, where frequent keystrokes and rapid code navigation are common.
  “When it was a good day, the quality was decent – almost like working locally, except that I couldn’t use a dual-monitor setup. But most days? Typing was laggy, and image quality was poor. It was frustrating.”
• Resource limitations: VDI environments are often under-provisioned for development tasks. Compiling large projects or running intensive tests can strain shared VDI servers.
• One environment, many tasks: Developers typically work on multiple tasks using the same VDI environment. This means manually checking out different branches, installing dependencies, and waiting for the IDE to index the project each time they switch tasks.

What can CDEs offer?

CDEs offer a modern, task-oriented workflow. They fundamentally shift the remote development paradigm by being project-specific and using optimized communication protocols.

• Latency and performance issues: Instead of streaming the entire desktop interface, only the IDE backend runs remotely, communicating with the local client via highly efficient data protocols. These protocols are far less bandwidth-intensive than video streaming, though they also require a stable network connection (latency below 100ms).
• Resource limitations: CDEs are ephemeral and can be provisioned with the exact resources and configuration needed for a specific project. As CDEs rely on cloud infrastructure, they are limited only by the cloud provider’s instance types. Moreover, with solutions like CodeCanvas, it’s possible to provision environments with GPU instances for tasks like ML model training.
• One environment, one task: CDEs shift the focus from single user-centric machines. For example, CodeCanvas is built around the concept of short-lived environments. Developers create a new environment for each task: bug fixing, feature development, or code review.
  The environment is fully pre-configured for the task (e.g. with the correct branch checked out, dependencies installed, and the indexes built) and is ready to use. After the task is done, the environment is deleted.

4. Costs

VDIs are notorious for their high costs, and one of the most common questions we hear from customers is whether switching to CDEs will save money. However, this question has no straightforward answer, as it depends on many factors.

What can VDIs offer?

VDIs have high fixed costs with not-always-efficient resource utilization:

• Persistent VMs: VDIs are often set up with persistent VMs, allocating resources even when the machine is unused. In some cases, companies leave machines running 24/7 to avoid the overhead of starting and stopping them.
• Infrastructure costs: The infrastructure required to run VDIs (servers, storage, networking) demands significant upfront investments. Scaling up adds further ongoing costs.

What can CDEs offer?

CDEs offer cost optimization. While CDEs rely on cloud infrastructure, which is inherently expensive, they offer more efficient resource usage. Environments are created on demand, and once they’re stopped, the resources are deallocated. CodeCanvas, for example, includes several features to optimize costs:

• Auto-shutdown: CodeCanvas automatically stops idle environments.
• Storage optimization: CodeCanvas can convert volumes of stopped environments from expensive block storage to cheaper object storage, further optimizing costs.

Although these measures can help reduce costs, let’s be realistic: Cloud infrastructure isn’t cheap, and the overall infrastructure bill for CDEs may not always be lower than for VDIs.

However, the actual savings with CDEs often come from reducing non-productive time rather than direct infrastructure costs. With CDEs, developers get ready-to-work environments, allowing them to start coding immediately without waiting for the environment to be set up.

Key takeaways

VDIs have their place in a wide variety of use cases, such as strict security policies and general-purpose remote desktops. However, they fall short in software development due to their limitations in UI responsiveness, standardization, developer workflow, and cost efficiency. CDEs, on the other hand, are purpose-built for software development, offering:

• An improved developer experience with low-latency communication protocols.
• Task-specific, ephemeral environments.
• Preconfigured templates for standardization.

While switching from VDIs to CDEs requires effort and investment, the long-term benefits to developer productivity, standardization, and cost efficiency make it a worthwhile transition. If you’re considering migrating from VDIs to CDEs, we recommend starting with a pilot project to evaluate the new approach’s benefits and challenges.

For more information on CDEs and how JetBrains can help you transition, visit the CodeCanvas product page and contact our team. We’re always happy to answer any of your questions!

Learn more about CodeCanvas