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.
^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.
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.
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.
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.
Using multiple screens, or larger screen resolution, is often limited by the screen resolution provided from a VDI.
Developers may encounter restrictions on installing software or marking certain system changes when using VDIs. This is usually due to:
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.
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:
Feature | Gitpod | VDI |
---|---|---|
Remote access to dev environments | Yes | Yes |
Faster onboarding | Yes | Yes |
Standardized dev environment setups | Yes | Not usually |
Automatically integrated into development applications | Yes | Not usually |
Centralized management of environments | Yes | Yes |
Install on your own infrastructure, including on-premises | Yes | Yes |
Easily scalable | Yes | May require additional infrastructure |
Low latency | Yes | No |
Portability across clouds | Yes | Limited, may require nested virtualization |
Keeps data off of endpoints | Yes | Yes |
Well suited for zero-trust networks | Yes | Yes |
Deploy in private networks | Yes | Yes |
Resource sharing during bursty workloads | Yes | Not usually |
Run native desktop applications | Through VNC | Yes |
Integrate with cloud-native technologies, such as service meshes, advanced observability tools, security tools | Yes | Not usually |
This website uses cookies to enhance the user experience. Read our cookie policy for more info.