What is a Cloud IDE?
As developers grow more interested in remote development and configuration as code, cloud-based integrated development environments (IDEs) show a lot of promise. Yet hardly any developers are using cloud IDEs.
So what exactly is an IDE? 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?
This blog will explain the basics.
What is an IDE?
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.
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.
What is a cloud IDE?
What defines acloud IDE is where the bulk of the development environment resides, especially the compute-intensive tools for debugging, building, and compiling.
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.
Two approaches to cloud IDEs
There are two general approaches to creating a cloud IDE:
- Create an entirely new IDE, which only runs in the cloud
- Take an existing IDE originally designed for running locally and move it to the cloud
IDEs that run exclusively 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.
Moving a local IDE into the cloud
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.
Benefits of using a cloud IDE
For individuals and organizations willing to make the move to a cloud IDE, there are some significant advantages over traditional localhost development.
Less setup effort
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.
Reduced build times
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.
Reduced personal hardware requirements
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 programming 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.
Concerns about Cloud IDEs
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.
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 the 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.
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."