Remote Development

Learn the ins and outs of remote development:
virtualization, containers, dev containers, and cloud.

Remote Development

Your work, where you want it

Software development has become a big, sprawling affair—lots of developers, lots of locations, and lots of services. It can be a bit much, and companies are looking for new approaches.

Remote development is a set of ideas that let developers do parts – or all – of their work on their desktop, on a company server, or in the cloud. This approach is appealing for many reasons: securing intellectual property, resource savings, better developer productivity, and more.

Let’s dive into the spectrum of remote development: what it is, how it works, who it’s for, and why you should care.

What Is Remote Development?

Developers write code on a computer. Sounds simple, but this means development is local: on their computer, with all their tooling, environment, and data. The developer is responsible for installation and ongoing maintenance.

That responsibility becomes a burden. Remote development gives developers a gradual series of new solutions:

  • Local virtualization
  • Containerization
  • Development containers
  • Cloud-based development

Let’s take a look at each of these in more depth.

Local virtualization

Working directly on a local computer has been the standard development approach for decades. As mentioned above, this approach has drawbacks:

  • Different developers have different CPU architectures, operating systems, and memory configurations
  • Each developer’s local configuration changes over time: OS upgrades, installed packages

In most cases, developers need environment isolation with a predictable “computer” to work in. Without isolation, “works on my computer” became a standard response to issue reports.

Local virtualization was a first step towards improving this burden. Products such as VMware, Parallels, Vagrant, and the Windows hypervisor provide an isolated “computer” within a computer. These tools provide a standardized hardware environment (CPU, memory settings, and operating system.)

Isolated sandboxes have advantages, but at a cost:

  • OS and application configuration still needs maintenance
  • Resource intensive (CPU, memory, disk)
  • Slow startup means these environments are long-lived
  • Network configuration can be error-prone

How does virtualization work in practice? If you have a macOS laptop but need to develop a Windows application, a product such as Parallels can give you a Windows “computer” inside your Mac. Regardless of the virtualization used, JetBrains IDEs provide the same programming environment across all operating systems.

Containerization

Virtualization gives physical isolation of hardware. But what if you are more interested in logicalisolation of the operating system and applications?

Containerization lets you specify the application as logical, specified units. You specify the version of an operating system, the application dependencies, and the pre-configured service processes which constitute your application. You can write these decisions into a configuration. Team members will then get the same logical unit.

Unlike virtualization, containerization does not provide hardware isolation. The upside: very fast container startup times. Fast execution, along with sharing of resources, means containers fit nicely into development processes.

Containerization provides a number of benefits:

  • Much less resource-intensive
  • Much faster startup
  • More maintainable
  • Repeatable configuration of all the units in your application
  • Logical unit(s) of development/deployment

While containerization has become quite mature, it still has some drawbacks:

  • Less isolation
  • Each container in a solution has to run the same operating system
  • Maintaining container configurations becomes its own responsibility

Containerization products have become quite popular: Docker, Docker Compose, Windows Subsystem for Linux (WSL), and Kubernetes all enjoy broad usage. As such, JetBrains IDEs have integration with all these, making them a natural part of development.

Development containers

Containers help run your application during development. But development involves developer tools and environments which are also complicated to set up. Can containers help run your tools? What if you could combine an application and its tools into one environment, and even run it remotely?

Development Containers (Dev Containers) provide such an environment. A dev container is an all-encompassing workspace for an application, development tools, libraries, and more. Developers can walk up to a project and get everything they need, locally or remotely, for a productive development environment.

Working with dev containers provides a number of advantages:

  • Developer tools can run in a container while integrating with IDEs
  • Dev containers can describe what “features” they offer as tooling
  • Broad ecosystem of standard development tool extensions
  • Reduces friction for cloud-based development workflows

Since dev containers are based on containerization, it inherits some of the same drawbacks. Additionally, dev containers:

  • Have a learning curve
  • Focus seems to be on cloud-native development
  • Linux-focus means XCode/iOS, Windows native might not be popular

Dev containers have seen broad adoption by vendors. JetBrains IDEs now support dev containers as a full-featured development environment for your projects. Dev Containers can be run remotely via an SSH connection or locally using Docker.

Cloud-based development

Containerization – and especially dev containers – helps manage development workflows. What if a company wants to move some or all of development away from a laptop, to a centralized facility?

Cloud-based development delivers a fully-remote workspace: the hardware, operating system, application, tooling, and the IDE in a public or private cloud. Developers only need a local “viewport” application to get the same familiar experience.

These remote workspaces provide a significant change in development, with many strengths:

  • Intellectual property never leaves central control
  • Very productive as developers just start working quickly, in any location
  • Lower expenses as resources can be easily shared and scaled
  • Some “cloud” solutions can run inside the company firewall

Remote workspaces have drawbacks:

  • Good developer experience requires a reliable, fast connection
  • Hosting costs could become a concern
  • Needs related infrastructure for orchestration, billing, etc.

JetBrains CodeCanvas, Google Cloud Workstations, Gitpod, GitHub Codespaces, and AWS CodeCatalyst are examples of popular private- and public-cloud development solutions. Additionally, these products support JetBrains Gateway, bringing our JetBrains IDEs into remote development. Also, JetBrains Fleet is our built-from-scratch IDE designed around a remote architecture.

Conclusion

Remote development is changing how companies and software teams work, whether logically-remote on a laptop or physically-remote across clusters in the cloud. The remote-development approach gives companies opportunities to streamline development, reduce cost, and secure intellectual property; all while staying one step ahead of the competition.