Introduction to Visual Studio Code Remote Development

vscode, devops, tools

By Cyprien ,

A couple of weeks ago, Microsoft released an extension for Visual Studio Code which enables Remote development. Remote development, what's that? Is it to develop on a remote server? Well, yes, but not only. It's just one of the many cool sides of this tool.

An explanation, maybe?

To enable this, they introduced a new component: VS Code Server. It's a UI less version of VS Code which can run extensions and offers an API for VS Code to connect. Basically, it enables Visual Studio to act as an UI, while everything really happens in a Remote operating system.  

Remote Development Architecture

That remote OS can be:

  • A physical or virtual remote machine over SSH.
  • A local or remote docker container. It even supports docker compose, so it's ready to support complex scenarios.
  • Windows Subsystem for Linux, so you can develop comfortably for Linux on your Windows desktop.

Of course, like other VS Code goodness, it's supported on Windows, OSX and Linux.

Use cases

So what could you do with that?

  • Reduce onboarding time of new developers. Yes it's not uncommon that it takes one or more days for a developer to go through all the readmes install the dependencies, navigate through the outdated steps and deal with some weird errors. You can solve that easily by using Containers. Some would argue it's not really new and they are right. People have been doing that since the inception of Docker. However, the experience just got 1000x better.
  • Ensure consistency between development and the production environment. Yet again, nothing fundamentally new, but experience and usability will make it worthwhile.
  • Work on a server 10 times more powerful than a local machine. It's not uncommon these days that you need to perform things impractical on a normal machine.
  • Isolation. Never ever have to deal with Sdkman, Nvm etc... Your local machine is not affected by the need of on project.
  • No more troubleshooting your coworker error. Yes we've all be there with an error a coworker is facing that no one has heard of before and which makes you want to say "reinstall everything from scratch".

Another one I really like is the capability to try out experimental version of sdk without messing up with your local environment.

Drawbacks

Well of course there are some drawbacks :(.

  • Performance: Working in a container or a virtual machine can come with performance hurdles. It can require a bit of tuning of various settings.  
  • Visual Studio Code: We all love Visual Studio Code but your experience will be limited by the quality of the extension available for your stack. At the moment backend development can be tough depending on your platform. (ex: debugging .net core on Linux/MacOS is painfully slow, but will be fixed in 3.0, kotlin support is limited)
  • Not open sourced: Yes, weirdly enough, Microsoft decided to keep this closed sourced. But I believe that the success of .Net Core and Visual Studio Code comes for a big part from the fact it's open source. It allowed the community to optimize things  or provide fixes for issues in a timely manner. However, because the code is shared with commercial products like Visual Studio (which will support this as well) it's will most likely remain that way (see FAQ).
  • No other IDE can support it: Other IDE are prohibited to support it by the license. It means it will always remain a VS Code and Visual Studio only solution.

Conclusion

Despite the current limitations of containers and  Visual Studio tooling, I really believe this is a case where the benefits outweigh the drawbacks. I think if you are an open source project Owner, you should really consider supporting it in your project so people can get started contributing in no time. If you are a business, you could really benefit from this by making sure your staff doesn't waste time installing and troubleshooting environments.

Credits