What’s So Great About Remote Development, Anyway?

You may have come across one or more of these products in recent months: GitHub CodeSpaces or JetBrains Space. So what, you say, why would I care about coding in my browser? I have a good computer, why do I need to screw around with remote connections, etc.? As it turns out, this journey for me started from a desire to code in my browser…

I like my iPad. It’s really good at many, many things, but it simply doesn’t have any native coding tools, nor is it likely to ever have them. Originally, I came across a project on GitHub called code-server. I think this project has now morphed into a couple of different forks now, and I don’t even know if the original still works since it seems to have forked into commercial offerings. In any case, this program allowed me to run VSCode full screen in Safari. That seemed to work reasonably well, but it felt pretty clunky.

CodeSpaces was a lot better than VSCode. I could add individual projects to my iPad home screen and get a near-native experience that was quite usable. I more or less left it at that until I came across JetBrains Space. Space offered the same thing, but for JetBrains IDEs. But the client is no longer a simple HTML5 client. It’s a full thick client written in Java. Again, this will never run on the iPad. I put it aside since it didn’t seem to serve any immediate purpose.

But then secure coding discussions came up. How do we prevent keep source code from leaving the organization? How can we support developers as the infrastructure components of our growing application grow accordingly? I remember when I first implemented RabbitMQ and provided instructions to developers on how to install it locally, there was a lot of grumbling. And, to be fair, they had a point. “Local Development Workstations” are not really a thing anymore given that many resources required by cloud applications don’t even have local analogues, or have very limited local analogues.

I thought about this for a long time. Remote development seemed like a good fit, but it just felt so clunky. Now there was a reason for it, though, so I tried again. After I figured out what the roles of the various JetBrains products are (Space Desktop, Gateway, IntelliJ-based IDEs), it actually seemed like a pretty good solution. I was able to run Rider IDE on an Azure D2. Latency through OpenVPN hovered between 70-100ms with the occasional spike over 100ms. System load for the IDE with a basic project is very reasonable for the debugging cycle. I could see needing a D4 for larger projects, though. Still, 4 cores is a relatively small VM and reasonably inexpensive when running Linux. (< $200 CAD/mo).

It’s important to put aside concerns about the idle desktop PC. That is not the problem we are trying to solve. We’re not even trying to figure out how to code on the iPad anymore (though that is a nice-to-have). The problem we are trying to solve is one of security and technical support. Security and Support have requirements that impose on developers slightly. It’s our job to make sure that imposition is as painless as possible.

One of the ways we can do that is to build shared infrastructure that developers no longer have to support. In my RabbitMQ experience above, I ended up having to do just that: build shared infrastructure so I didn’t have to support multiple developer workstations. Instead, I only had to support a single development cluster and come up with a way the application could share a single configuration file and cluster, while still allowing for easy developer onboarding.

So, our massive local development workstation turns into a series of smaller purpose-built VMs and PaaS services and a netbook (or a developer’s personal device, if the corporate security can accomodate it). I’m not going to pretend this is cheaper than buying a laptop every couple of years. Indeed, a quick estimate shows that the cloud environment is about twice as expensive. This is a trade-off that you’ll have to decide on yourself. In our circumstances, the security and infrastructure support concerns win out for us, ymmv.

It took me a long time to see the benefits of remote development. For the individual, beyond the very narrow use-case of coding in a browser, it’s not really there. It’s not until you start worrying about your code and data walking out the door, or how you’re going to support that developer in India that any of these costs start to make sense. But, remote development does provide solutions to both of those concerns that are not easily satisfied by issuing physical hardware to developers.

To conclude, it looks like Microsoft has hopped on this bandwagon too with their vscode-server, currently in private preview. If it’s anything like code-server, it should provide a similar in-browser experience to code-server, with hopefully less of the clunkiness. Having used github.dev, vscode.dev, JetBrains Space and Gateway, I think I can say I’ve covered most of the gamut of possibilities. The JetBrains offering definitely feels the most integrated right now, but doesn’t run on the iPad. Maybe one day I’ll get both!

Advertisement
,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: