A software development environment is not a container

Ammar Bandukwala

 on November 5th, 2022

As software projects scale, so does developer time spent fiddling with environments and waiting on tests and builds. Developers who work in large, mature companies are awfully familiar with these problems. Some of the enterprises we've spoken with take weeks to onboard a new development environment, hours to clone their repository, and 30 minutes to produce a development build.

Bleeding edge organizations like Palantir, Slack, and Stripe have largely solved these problems by shifting their development environments to cloud servers that automate configuration and offer immense computing power. But, most companies that could benefit from remote development struggle to dedicate the engineering resources required to build an internal platform.

Coder was founded five years ago to standardize remote development. In 2021, our v1 began making serious headway in the enterprise, revolutionizing software development in some of the world's largest banks, software companies, and public sector organizations. But, due to our container-based model, we couldn't explain how every software engineer in an organization would switch to Coder, so most opted to stick with local development instead of bifurcating their teams across two workflows.

See, Coder v1 and similar tools dictate that a development environment is either a container, VM, or group of packages. It's all of the above and more. We quickly learned that to realize our vision, we must adopt a new core tenet.

A development environment is a set of cloud resources namespaced to a single developer.

This tenet and our years of market discovery have culminated in the open-source release of Coder v2.

Now, we leverage Terraform to support every type of computing, whether that’s Windows VMs on Azure, Macs on AWS, or Linux Containers on Docker. With Terraform's thousands of resources, one can provision load balancers, buckets, security groups, secrets, etc. in their workspace.

Our users self-install Coder onto their clouds, so they don't pay Coder a premium on compute or worry about our access to sensitive information. Coder doesn't require network infrastructure setup since we transparently leverage Tailscale to connect local machines with Coder environments. Developers have two ways to access their environments:

1. Via the coder CLI, developers can use SSH and port-forwarding with familiar local tools such as Visual Studio Code Remote SSH, Emacs or VIM
2. Via the web dashboard, developers can use code-server, JupyterLab, and other web applications

To set up Coder, an administrator first writes a Terraform template that describes each workspace’s cloud resources.

resource "aws_instance" "dev" {
  ami               = data.aws_ami.ubuntu.id
  availability_zone = "${var.region}a"
  instance_type     = var.instance_type

  user_data = data.coder_workspace.me.transition == "start" ? local.user_data_start : local.user_data_end
  tags = {
    Name = "coder-${data.coder_workspace.me.owner}-${data.coder_workspace.me.name}"
  }
}

Then, a developer spins up their workspace.

Last, the developer connects and begins coding.

There’s much more to be done, especially around IDE support, cost management, and, of course, airplane Wi-Fi. But, we’re incredibly excited to share our tool with the world because we believe it’s the next step in realizing remote development.

If you’re interested in learning more, check out our repo or install.

— Ammar Bandukwala, Co-founder & CEO