I have spent a decade in charge of development tooling teams. During that time, I watched the rise and fall of Vagrant and the introduction of Docker and a plethora of other build tools. I remember when most developers had two desktops under their desks, and I helped with the mass migration to Mac laptops. I also helped develop internal platforms for self-service compute on AWS. All of these tools were intended to bring production environments closer to development and provide easy configuration and scalability of the local environment. However, none of them nailed it.

Since Palantir, I’ve talked to many different developer experience leads. It turns out that there are some common themes.

• Many developers suffer from poor performance on their laptops. This could be due to any combination of poorly tuned security tooling, heavyweight local processes, and, often, Chrome just being a big hog.
• Most companies struggle with the Mac vs. Linux vs. Windows argument. In the majority of cases, the IT team is stuck provisioning all three. There’s always some tool or library that works differently enough to cause a problem. Then, something like Mac’s M1 chip comes out, and all hell breaks loose.
• Front-end developers struggle to collaborate with UX designers. Especially in this remote world, most companies do not have good setups for helping designers and developers collaborate. Many companies still rely on screenshots or short videos to demo new UI components — gross.
• Highly performant laptops are expensive. If you have a compute-heavy application, you are probably shelling out $4k per developer, and another $4k every time they get drunk and leave their laptop in a bar.

But honestly, none of that matters compared to this:

• Most engineers are not delighted by their local environments. Be honest: do you find your laptop to be a joy to use? Does your laptop get in your way? Or empower you?

If you absolutely love your laptop and have never had to close out of most of your applications to get your damn Teams meeting not to stutter, then this blog post is not for you. Go away.

Remote development involves having a remote machine performing all build and test processes, with your laptop serving as merely a browser or thin client.

Want to skip reading the rest of this article? You can just head straight to this GitHub Repo and try out Coder OSS in 20 minutes. Only keep reading if you want to know more about why remote development is the superior development environment.

If you like this post, please 👏 , subscribe, or follow me on medium or LinkedIn to let me know I’m on the right track!

· Why is remote development better than local development?
· Spin up a remote development ecosystem in under 30 minutes
· What types of problems does remote development solve best?

Why is remote development better than local development?

Remote development significantly improves developer productivity

The core argument for remote development is that by moving the development workload to a remote machine, you are able to move, configure, and scale the remote machine significantly faster than you could distribute new laptops to your development team. If the remote machine is optimized for your use case, it can do the following.

• Improve build and test speeds: The underlying VM can be scaled and optimized to fit the needs of each individual project. In our experiments, we got the build speed from 9 minutes down to 2.
• Reduce latency: By placing your remote environment into the right region, one can significantly reduce their distance to their infrastructure or cloud APIs. For an Australian developer working on US East based infrastructure, this improved several processes by 10x.
• Eliminate time-consuming setup steps: Every repository has setup steps that can be automated, which is much easier when you control the workspace. This is especially true in large organizations with older repos. Automate the install once, and save everyone the time.
• Multiple environments. When performing a major update to a library, you can spin up a second workspace in parallel for this use case. This keeps the environment modifications contained, enabling you to continue to write code against the original code base.

I first ran across this model with an engineer who was using code-server (note the 57k stars) on a remote VM. His driving issue was that he was unable to check out and build a large code base because his laptop was so bogged down with security tooling that his IDE would crash. My mind was blown, but I realized that this model wasn’t going to scale. VMs can be very expensive and running one or more environments per developer would be unreasonable. Developers only need their environment running during working hours, and this type of usage is perfect for Kubernetes.

Kubernetes and remote development

Deploying the remote development environments as a Kubernetes pod solved my cost and setup problems. I could control the execution environment, base images, and security practices, and I could utilize the cost advantages by scaling up and down the computing capacity as developers started and stopped their workdays.

As illustrated above, the idea is that each developer has their own persistent volume, but their underlying container can be made ephemeral. Since storage costs are a small fraction of the total compute costs, this enables developers to run really powerful containers during their workdays while their company spends only pennies in the evenings and weekends.

Do I actually believe that local development is dead?

Ok, fine — I don’t actually believe it will die, but not because I have a very compelling argument. Large organizations like Google and Facebook have been using a remote development model for years, but the OSS tooling to make this experience great has taken a while to catch up.

The most reasonable counterargument is that remote development is not ideal for developers that work in areas with spotty internet. While this is true today, with efforts like Starlink and ASTS, I believe that we are only a couple years away from globally accessible internet to be a reality for all.

The second most reasonable counterargument is around the remote development experience of the JetBrains suite of IDEs. JetBrains released Gateway in 2021 to address these issues. Unfortunately, JetBrains’ Gateway was rough at first, and I would not have recommended it for full time IntelliJ or Webstorm users. However, it has made significant advancements in the last year, and I expect that within 1–2 years, users will find it equivalent to local development.

To be frank, the primary hesitation is a lack of belief that a browser-based IDE would be acceptable to a full time developer. It’s got to be laggy, difficult to use, unreliable, or something unpleasant right?

This is where CoderOSS shines. It’s a free way to see for yourself what a remote development experience could be like for your developers. Trying it out yourself is the best method.

Spin up a remote development ecosystem in under 20 minutes

I’ve built an easy-to-use repo as a demo path to show what a remote Visual Studio Code on Kubernetes looks like. I chose to use Google’s hosted Kubernetes service, as they offer a $300 credit and GKE Autopilot is dirt simple to use.

Coder install instructions:

• Create a Google Cloud Account, a project, and a service account in that project with editor permissions.
• Fork my repo and set it up with spacelift.io or equivalent
• Set GOOGLE_CREDENTIALS and TF_VAR_project with the project id from above
• Run and apply the Terraform.

The entire setup should take you less than 10 minutes, though if you are new to Google Cloud, it might take you a little bit longer.

Coder setup Instructions:

• Navigate to the IP address of the load balancer (Google Cloud / Kubernetes Engine / Services & Ingress.
• Create the initial username and password.
• Go to Templates / Kubernetes / Create Workspace and give the workspace a name.
• Within three minutes, you should see this:

• Clicking ‘code-server’ should open up a new browser tab with VSCode running on the remote system.

Not sure about you, but this blew my mind the first time I saw it in action. I was used to a world of Windows RDP or VNC, and the idea of using my browser as my full-time IDE seemed like a gimmick. After seeing it in action, though, I was sold.

What types of problems does remote development solve best?

Having led a developer experience team for years, and as a devout believer in DevOps (at least, DevOps as described by the Phoenix Project), I can say that while optimizing your company’s development workspace is important, it might not be your most important problem. If any of the problems listed below are one of your top issues, then remote development is worth exploring.

Problems that are well-suited for remote development

• Long build, execution, or test times (>5 minutes) are usually limited by some combination of compute, memory, disk, network, latency, or even operating system. All of these can be adjusted with the remote development model, and can be done on a case-by-case basis.
• Patching old code can be time-intensive if the engineer has to get their local workstation set up to work with historical releases, legacy code, or just rarely touched codebases. If you wrap the environment in a container, setup is no longer manual and is limited only by the boot time of the container. In addition, tools like Coder support spinning up multiple environments per developer, enabling them to spin up dedicated environments for hotfixes without disrupting their current work.
• Securing source code (i.e., air-gapped) is necessary when you are dealing with regulations (i.e., ITAR), financial systems, or safety-critical systems. Many of these organizations strive to go fully air-gapped to prevent source code leakage. It is much harder to maintain air-gapped development laptops than it is to maintain a remote development container.

Development types that lend themselves well to remote development

• Front-end development can see a large boost in development productivity due to increased compute/memory capacity, and VSCode (the most popular IDE for frontend development) works very well with remote development due to coder/code-server and its ability to do remote backend over SSH. In addition, Coder supports remote dev URLs, which enable developers to collaborate with designers on the actual product instead of through screenshots in GitHub PRs.
• Kernel or any cross-operating system development can be improved because you are running the IDE on the operating system for which you are trying to develop. Coder’s OSS model isn’t Kubernetes specific, and you can provision VMs instead.
• Air-gapped networks are a great use case because you don’t have to spend nearly as much time futzing with the workstation. An engineering team outside the network can create the base image that gets imported into the internal network. This is great for banks, healthcare, or military use cases.

Wrap-up

Remote development is quickly taking over as an alternative to local development, and the Kubernetes model seems to be the most compelling version of this. An engineering team can easily double the memory capacity of their team’s containers, but doubling their laptop memory is excessively expensive. No matter what you try to do to optimize your code, in the end, you are often stuck at the mercy of Chrome or resource-hogging security tools.

The Kubernetes remote development model encourages the full encapsulation of the development requirements, which pays major dividends for companies that have to deal with historical releases or legacy code. The Kubernetes model also enables horizontal and vertical scalability, preventing your developers from ever being inefficient due to “performance.” Finally, your finance team will thank you for the cheaper laptops.

While remote development has long been a common practice for software giants like Google and Facebook, Coder OSS has opened the doors to make it readily accessible to companies of any size. If you followed the instructions in my repo, you were hopefully able to see this live for yourself in under 30 minutes.

I hope you enjoyed this post. If you did, please clap, follow, or hit me up on LinkedIn to let me know that I hit the mark.