Why are Cloud Development Environments Spiking in Popularity, Now?
Tech companies are building their cloud development environments (CDEs) and dozens of vendors are launching their offerings. But why now?
Two months ago, we covered the quiet revolution unfolding at tech companies: cloud development environments (CDE.) We went through the ideas behind CDEs, their upsides and downsides, and case studies in the use of this tech at Uber, Slack and Pipedrive.
In this issue, we explore why CDEs are taking off now, and get insights from an engineer who has worked in the CDE space for 7 years, Mario Loriedo, senior principal software engineer at Red Hat, tech lead of open source project, Eclipse Che, and a Cloud Native Computing Foundation ambassador.
We cover:
Why are CDEs gaining popularity, now?
Virtual desktops vs CDEs
The evolution of the CDE space since 2016
The biggest challenges of the CDE space
The future of software development in local environments
See also the other two articles on this topic:
1. Why are CDEs gaining popularity, now?
The concept of remote development environments stretches back to the dawn of computer programming. In the 1960s, expensive central computers were shared by many users, sitting at terminals. Each user had a specific amount of time to use the processor in this setup called “timesharing.”
Cloud development environments are similar to how programmers used a terminal to program a central computer, back then. A big difference is that in the case of old-school timesharing, the goal was to save on infrastructure costs, as the cost of CPU cycles was far higher than programming time. A single mainframe machine cost several times the annual salary of a programmer; the Atlas computer at Manchester University in the UK cost £50M in today’s money, the equivalent of several hundred programmers’ annual salaries. No wonder compute time was so valuable!
Today, it is compute that’s much cheaper than software engineers’ time. In the US, a software engineer working at a Big Tech company is compensated more than 100 times the cost of a high-end laptop, annually.
So why the sudden rise in use of remote environments? I observe several trends which make this shift understandable and sensible:
Here are the reasons:
1. Larger codebases. Every day, there’s more code at a tech company, not less. This means more repositories are needed, which are fast enough to build and work with, but which increase fragmentation. At many large companies, this inevitably leads to consolidating many smaller repositories into fewer, larger ones. Which leads to the next point…
2. Monorepos. These are becoming more popular at large tech companies for a few reasons. The biggest is consistency; with a monorepo, dependencies are clear and API breakages due to outdated dependencies are absent. Also, tasks like integration testing are much easier. However, monorepos result in codebases growing large, so that even checking out the code or updating to the head can be time consuming.
3. Laptop compute power is plateauing. The available compute power of laptops and personal computers no longer increases as it did prior to 2010. Moore’s Law says the number of transistors in an integrated circuit (IC) doubles around every two years. But the most recent 10 years suggest this is no longer the case.
4. The Cloud is spreading and offering more capabilities. Since around 2010, there’s been a boom in Cloud computing. AWS launched in 2006, Azure in 2010, and GCP launched its first region in 2015. Since then, all Cloud providers have expanded their availability, and the price of Cloud compute has dropped due to competition and technological progress.
5. Low-latency networking is cheaper and more common. CDEs only make sense when latency is low. This requires high bandwidth internet connectivity for developers, and remote development environments to be located in close vicinity to servers. High-bandwidth networking is spreading rapidly, including fallback options with mobile 4G and 5G coverage. And with cloud providers launching new data centers, zones and regions, it’s now easier than ever to have cloud environments near to software engineers’ locations.
For example, Uber runs its Devpods out of 5 data centers this way, presumably operated by a provider like Google Cloud.
6. Developer productivity investments. Assuming a team of four software engineers costs $1M/year, would you spend $10K/year to improve the efficiency of that team by 10%? The answer should be a no-brainer ‘yes,’ because the business value generated by a team costing $1M/year should already exceed $1M/year. So if the team gets 10% more efficient, it should generate at least $100K/year extra value.
At companies with large codebases, CDEs are a pragmatic way to increase the productivity of software engineers.
7. Remote work. Covid-19 lockdowns and the rise of remote working have played a role in boosting CDEs. With remote work, engineers spend more time on video calls, which utilizes laptop resources like CPU, memory, and more. Executing a build is much slower while on a call. Plus, a CPU and memory-intensive build can impact the quality of the video call, and make the local environment much less responsive.
LinkedIn gathered data showing how much slower video calls make common developer operations. It found video calls added a 2-4x increase in latency to a developer laptop.
8. Concern about code leaks. One downside of remote work – and hiring people whom you’ve not met in person – is that trust problems tend to arise more easily. When working from the office, it’s easy to verify that the same person you hired is the one doing the work, remotely. With full-remote work, the risk is higher that someone other than the employee accesses the codebase.
CDEs can offer an additional layer of protection to reduce the risk of source code leaking outside of the network. At the very least, far more logging is in place, and it can be easier to detect when larger parts of the codebase are accessed and copied across the network.
9. Open source VS Code Server. In 2021, Microsoft open sourced VS Code Server. This is the server code that powers VS Code remote development, and GitHub Codespaces. Thanks to this, the barrier to entry was dramatically reduced for anyone wanting to build their own cloud development environment which supports VS Code. This applies to startups offering CDE solutions, as well as companies building such a solution in house.
None of these trends alone can explain the spike in popularity of cloud development environments, but their combined effect in recent years does provide a plausible explanation. It’s also possible to posit that the “spark” which ignited this confluence of factors was the Covid-19 pandemic of 2020-21, and the accompanying rise of remote work.
2. Virtual Desktops vs CDEs
One interesting thing about cloud development environments is that there’s been a very similar technology to it in existence for nearly 20 years: virtual desktop infrastructure (VDI.) This is a technology that runs virtual machines on a corporate server, and employees access the machine remotely:
Components of a VDI solution:
Clients: machines employees use to connect to virtual machines. These could be laptops, a web interface, a mobile device, or other.
Connection broker: the component responsible for authentication and authorization, ensuring a secure connection (typically via Single-Sign-On, shortened to SSO,) and managing sessions and desktop pools.
Hypervisor: also referred to as a virtual machine monitor (VMM.) The hypervisor segments physical servers into virtual machines. The hypervisor shares the underlying machines’ resources of CPU, memory and disk, and creates multiple virtual machines on one physical machine.
The concept of virtualizing desktops gained momentum in the mid-2000s, with VMWare and Citrix being two notable vendors in the space. Here’s a brief overview of the history of VDI from the book, Mastering VMware Horizon 7 by Peter von Oven and Barry Coombs:
“The concept of virtualizing Windows desktops has been around since as early as 2002, when VMware customers started virtualizing desktop workloads and hosting them on a VMware server and ESX servers in the data center. As there was no concept of a connection broker at that time, and neither was the phrase VDI really used, customers simply connected using the RDP protocol directly to a dedicated desktop virtual machine running Windows XP.
It wasn't until 2005 that VMware first showed the idea of having the concept of a connection broker. By demonstrating a prototype at VMworld, VDI entered the limelight, raising the profile of the technology. It was also at the same event that companies such as Propero showed their version of a connection broker. Propero would later become the Horizon View connection server.
In early 2006, VMware launched the VDI alliances program, with a number of technology vendors such as Citrix, HP, IBM, Sun, and Wyse Technology joining this program.
By 2007, the prototype connection broker was introduced to customers to help with development before it was given to the VMware product organization to productize it and turn it into a real product. The released product was called Virtual Desktop Manager 1.0 (VDM). (...)
In 2010 (...) this was also the year that VMware talked publicly about the biggest VDI reference case to date with Bank of Tokyo Mitsubishi, who deployed 50,000 virtual desktop machines.”
So it was around 2006-2007 that VDIs really started taking off across the industry. Their biggest benefits are:
Security. The biggest driver for most VDI solutions is that what’s on the virtual desktop, stays there. For example, source code doesn’t move onto a developer’s laptop, and there are no unauthorized installations of frameworks or libraries.
IT support. With VDIs, IT staff do not have to support a host of different configurations, as the company will support a select few virtual desktop configurations.
Overall hardware cost. It can be possible to save on overall hardware costs by having low-end laptops or PCs connect to beefy, on-prem servers.
VDIs have downsides, too:
Performance. Working through a virtual machine can feel sluggish, and network latency is especially noticeable with a lower bandwidth internet connection, or when far away from the server running the virtual machine.
Less flexibility. It’s much more time and effort to get custom tools installed on a virtual machine, and this is often discouraged by design.
VDIs have been popular in industries where the benefits heavily outweigh the downsides, such as finance and banking for which security is particularly important.
However, CDEs offer benefits which VDIs do not:
Improved developer experience. Developers can customize their development environment much better, and install tools on their local machine with far more flexibility than with VDIs.
More room to optimize performance. Latency is as important with VDIs as with CDEs. However, it can be easier to run VMs closer to developers’ machines with CDEs by utilizing public cloud provider infrastructure.
Potentially lower cost, overall. CDE containers tend to be much shorter lived than virtual desktop machines, and often have lower resource needs. It can be cheaper overall than running a VDI – but not always.
These benefits make CDEs a tempting alternative to VDIs. And CDE is a “new kid on the block” technology, which makes it exciting and there’s also more space for innovation. Therefore, I can see CDEs being suggested by engineers at companies already using VDIs.
3. The evolution of the CDE space since 2016
For this part of the article, we’re joined by Mario Loriedo, senior principal software engineer at Red Hat. Mario has lived and breathed this space for 7 years, and brings an expert viewpoint. But first, a little personal context.