Most software now has some cloud component, either the app running entirely on the web (e.g. Google Docs, Salesforce, etc.) or more commonly using the web for distribution and installation. Despite this trend, software is still typically written on individual laptops and workstations in local development environments configured by the developer. These integrated development environments (IDEs) typically consist of at least a code editor and tools for debugging and building and have historically been built to be installed and configured on individual machines.
With increased interest from developers in topics like remote development and configuration as code, the idea of taking the IDE to the cloud where it can harness benefits like zero environment configuration and additional compute resources holds much promise.
Yet, a 2020 JetBrains study found that only 10% of professional developers currently use a cloud IDE, a one-point rise over the previous year's survey. There are [many reasons why] developers have been slow to embrace cloud-based IDEs, some of which we have written about before from our past experience.
But how do the cloud IDE options available today differ from local developer environments and why should more developers consider using them, more so now than ever before?
When people usually think about cloud IDEs they envision an environment running on a server somewhere and accessed entirely through a browser window. This is indeed the typical model. However, some offerings also allow you to run an editor locally while the other components of the IDE run in the cloud. The distinction is important, as we will see, but for my purposes here I will consider both to be cloud IDEs. What defines a cloud IDE is where the bulk of the development environment resides, especially the compute-intensive tools for debugging, building, and compiling.
There are two general approaches to creating a cloud IDE. The one approach is to create an entirely new thing, an IDE that only runs in the cloud. This is the approach of Codeanywhere and Cloud9, two of the first cloud IDEs. The primary advantage of this approach is all components of the IDE can be deeply integrated because the product is cloud native. The primary drawback is that users must adopt a toolset with which they may not be familiar, and developers are often fiercely loyal to their preferred workflows.
The other approach is to take an existing IDE originally designed for running locally and move it to the cloud. This is the approach of code-server, the open source project that we maintain, and GitHub Codespaces, both of which allow developers to run VS Code remotely and access it through a browser. Commercial products using this approach often support multiple editors accessed through the browser. Gitpod users have a choice of VS Code or Eclipse Theia, for instance, while our own product Coder supports VS Code and any JetBrains-based editor. A major advantage to this "adapt for the cloud" approach is that developer adoption is typically easier since the environments include toolsets with which they are intimately familiar.
For individuals and organizations willing to make the move to a cloud IDE, there are some significant advantages over traditional localhost development.
Most developers spend between 2-8 hours, and sometimes more, setting up a new dev environment locally. With cloud IDEs developers are typically logging into an existing online editor or launching environments as containers from existing images. They can begin coding in minutes, if not instantly.
When your IDE is in the cloud you are no longer tied to your individual machine. Want to spend a week working from a tropical island instead of the office? No problem. Your laptop in the shop for repairs and you only have a tablet available? It's still possible to write code on an iPad, too. In most cases, all you need is an internet connection and a browser. Of course, if your tropical island lacks internet connectivity you are better off coding on your laptop, but you'd probably be even better off closing your laptop and enjoying the views.
With cloud IDEs, developers no longer need to build and configure a development environment on their personal machines. This saves them time, ensures that all team members on a project are working with the same environmental settings, and can reduce configuration drift as a result.
Developers spend a great deal of time waiting, waiting for builds to compile, for tests to run, for applications to deploy and load, etc. With a cloud IDE, those times are typically reduced because rather than depending upon the resources of the developer's own machine the IDE is tapping into the resources of its cloud infrastructure.
Because the compute is handled by the cloud, developers don't require high-powered machines themselves. As mentioned above, it even becomes possible to code using a tablet. For businesses, this translates into cost savings as they can provide less expensive hardware for their employees. Companies could even implement BYOD (bring your own device) policies when utilizing contractors and other temporary workers.
Cloud IDEs also foster collaboration with some offerings permitting pair programing or even live collaborative editing as with Google docs. Some cloud IDEs also make it easier for developers to share the applications they are developing while in progress.
With all the advantages of cloud IDEs you might think that more than just ten percent of professional developers would be using them regularly. There are a number of concerns that have slowed adoption.
Latency is probably the single most cited concern about cloud IDEs from developers. As one developer put it, "If you have fingers that walk on water, even the slightest blip is noticeable and drives you nuts." Certainly, if you have ever tried to use a VDI or remote desktop you have likely experienced the kind of keystroke lag that drives users mad.
However, most cloud IDEs like code-server use web elements instead of streaming an image back to the local device. This eliminates the need for a round-trip from user's keyboard to server and back to the user for text to appear on the user's screen.
Having to adopt a new workflow
"Developers are a finicky bunch," wrote John Biggs and Ryan Donovan on the Stackoverflow blog. "Like a dog refusing to walk on wet grass, there always seemed to be a bit of resistance to changing up a routine." Briggs and Donovan were writing about the surprisingly large number of developers who still prefer Vim and Emacs over modern IDEs. The fact that Biggs and Donovan could write that post in late 2020 exemplifies the resistance many developers have to moving to a cloud IDE.
The most successful cloud IDEs in terms of adoption over the coming few years will certainly be the ones that allow developers to continue using the tools and workflows they already love while also easily demonstrating how using them in the cloud is better.
If you want to adopt Codespaces as your cloud IDE then you are limited to using GitHub for version control. If you want to use CodeReady, then you have a choice of Git repositories, but you are committing to running OpenShift on Red Hat Enterprise. After being purchased by Amazon, Cloud9 is now only available on AWS.
Vendor lock-in is more of a concern for businesses than individual developers. However, with many organizations taking a hybrid and/or multi-cloud approach to their computing needs, vendor lock-in is a major consideration when picking any cloud-based service, including a cloud IDE. If vendor lock-in is a concern, then businesses would best be served by looking at cloud IDE offerings that are not projects of companies whose primary revenue stream is another product or service that comes as a package deal when using the cloud IDE. Both Coder and Gitpod meet this criterion. Such offerings are also more likely to support multiple editors through the browser, as well as multiple Git repositories and deployment on a variety of cloud providers or even on-premises installations.
Cloud IDEs clearly offer significant advantages for developers and businesses willing to consider the move away from traditional localhost development.
If you would like more information about the advantages to be gained by moving software development to the cloud, as well as how to overcome resistance to such a change within your own organization, check out our playbook "Software Development in the Cloud: How to Get There."