February 22, 2024Platform Engineering

Writing software with chopsticks: the challenges of Virtual Desktop Infrastructure

A review on the common challenges impacting developers who write code using VDIs, and an alternative approach to solving those challenges using cloud development environments.

To put it bluntly, VDIs damage developer experience. They are a general-purpose security solution that have never been tailored to software development practices. Yet so many developers are forced to use VDIs, especially among highly-regulated industries like financial services, health care and telco.

The answer doesn’t have to be to petition to remove your VDI or worse, engage in insecure software practices. It’s entirely possible to both improve developer productivity and keep security teams happy without compromising compliance certification such as HIPAA or ISO27001.

In this post, we’ll discuss the challenges to writing code on developer workstations and review an alternative solution that still checks the box for all of your security requirements. Let’s first get aligned on what a VDI actually is.

‘It’s anti-developer. Period. Full stop.’

^Words from a developer reflecting on their use of VDIs.

Virtual desktop infrastructures (VDIs) are a form of virtualization that enables remote access to a full desktop environment. VDIs host the operating system, applications and data from a desktop environment on a virtual machine and stream them to end-users over a network.

In theory, VDI setups should not interfere with developer experience. Their purpose is to duplicate a desktop in order to provide remote access to end users, or limit the actions that end users are able to take when accessing sensitive information (i.e. preventing users from downloading information to their laptops, etc.). But in practice, developer experience is significantly impacted.

Developer experience challenges when using VDIs

Below are some of the challenges developers face with their VDI setups. Some related to inherent challenges with VDI technology and others coming from how organizations set up their VDI solutions, and the policies they have in place around them.

Constantly losing state

VDIs can be ‘persistent’ and ‘non-persistent’. This refers to how user data and customization settings are managed and stored across sessions. In persistent setups, VDIs maintain state across sessions. In non-persistent setups, the environment does not save user states between sessions.

In non-persistent setups, environments do not save user states between sessions. The advantages to this are mainly cost savings but as you can imagine, for developers, removing the customizations they make such as installing tools or configuring their editors can lead to hours wasted on a daily basis.

Incorrect operating systems

VDI solutions are often provisioned with windows machines while many development tools are often optimized for Linux-based operating systems (OS). If the developer applications being used depend on Linux as the OS, workarounds can be put in place, but this will often lead to ‘works on my machine’ issues where the developers’ local environments end up leaking bugs to production because they are different from the upstream environments.

Inability to use dual monitors or larger screens

Using multiple screens, or larger screen resolution, is often limited by the screen resolution provided from a VDI.

Application installation restrictions

Developers may encounter restrictions on installing software or marking certain system changes when using VDIs. This is usually due to:

Latency and resourcing issues

Latency in a VDI context refers to delays between a user’s action and the response from the VDI environment. They are the number one complaint from VDI users as they are the most impactful to development workflows. Some factors that contribute to latency are:

The pain developers feel related to these latency issues show up in routine development activities:

To mitigate the issues, enterprises can adopt strategies like optimizing network infrastructure, understanding which protocols are best for their workloads, server performance and sizing, etc. However none of these mitigations will address the core of the problems surrounding developer experience because VDIs were not built for development. Enter cloud development environments.

Remote developer workstations with optimized developer experience

Cloud development environments (CDEs) are development workspaces pre-configured with all the tools, dependencies and libraries required to start coding. They are similar to VDIs in that they are both virtualized technologies enabling a remote experience. Their key difference, CDEs were purpose-built to improve developer experience.

CDEs can be used for:

They can also be used for the same security benefits as a VDI setup:

Given these benefits, CDEs are the recommended solution for enabling secure, remote development in a way that doesn’t hinder typical developer workflows. If you absolutely must use VDIs because of organizational mandates, we’ll cover how to best use VDIs and CDEs together in a follow-up post.\ In the meantime, here is a helpful feature comparison to see how Gitpod stacks up to your typical VDI:

FeatureGitpodVDI
Remote access to dev environmentsYesYes
Faster onboarding YesYes
Standardized dev environment setups YesNot usually
Automatically integrated into development applications YesNot usually
Centralized management of environments YesYes
Install on your own infrastructure, including on-premises YesYes
Easily scalable YesMay require additional infrastructure
Low latency YesNo
Portability across clouds YesLimited, may require nested virtualization
Keeps data off of endpoints YesYes
Well suited for zero-trust networks YesYes
Deploy in private networks YesYes
Resource sharing during bursty workloads YesNot usually
Run native desktop applications Through VNC Yes
Integrate with cloud-native technologies, such as service meshes, advanced observability tools, security tools YesNot usually

This website uses cookies to enhance the user experience. Read our cookie policy for more info.