With the convenient of laptop workstations and the advancement in battery performance. A lot of developers work have moved to having their development environment on a work laptop instead of a dedicated workstation; however, this convenience does trade the performance benefits of a workstation for the convenience of a mobile platform, which also has a damaging effect on battery life of the laptop device, severely setback the benefit of the setup. This article hopes to provide an alternative which will ease the constraints of a mobile device regarding performance and power consumption with a remote workstation. 

1. The future standard for development environment?

Developers at Google have been using a remote environment for developments for a long time. Mostly due to their requirements around massive mono-repos and the hassle of setting up a development environment, which takes away valuable developer time. A remote environment allows for organizations to build reproduceable environments for different project needs with tools like Nix. Alternatively, simply clone an existing VM. This enforces environment standards and provides additional security against attack vectors that targets a developer’s machine.  

Recently, with the announcement of Project IDX and Microsoft’s Vscode Online features, these large companies have started to provide these internal tools to the public. Still, it is good to be vigilant about these tools and contemplate if its usage is appropriate for your and your organization needs.  

2. The problem space

A) The advent of docker

With the popularity of Docker images for local web development and CI/CD pipelines, the demands on a computer hardware have increased significantly. Especially on non-Linux operating systems such as MacOS and Windows (where a significant amount of developers are using as their local development environment). This is due to Docker needing to run a virtual machine on non-Linux host system to emulator a Linux environment, which comes with severe performance penalties. There are also certain quirks regarding container networking working differently across different platforms, leading to variations and the needs for some additional setups. 

B) LSP, AST, and other file analytic tools

During my time developing Nodejs application with typescript, I noticed the CPU usage for ts-language-server was quite high, which leads to the editor completely hangs while it was trying to load the auto completion. This problem occurred quite regularly and have lead to a rather frustrating editing experience, and it happened on both vscode and neovim, which narrowed the problem to the language server itself (someone should rewrite the thing in rust). Turns out, parsing text and running tools of large project does consume a lot of computing resources in term of RAM and CPU, which leads to the sluggish experience. 

3. Remote file editing

The hassle free VPN setup

One of the largest hassle for setting up a remote work station would be how to setup a secure connection over the internet for connecting your devices. There are 2 approaches to this problem, you either use a public facing IP address to allow direct access to your workstation and use SSH for authentication. Or rather, you use a VPN network between your devices and assign your workstation a local IP. Below I will offer two solutions for the use cases; 

A) Public IP with URL: Cloudflare Zero Trust – Cloudflare Tunnel – Cloudflared Access

• Create a tunnel from your server to the cloudflare network (You can also use this for public hosting your website without needing a public IP address) 

• Setup device enrollment rule and SSH keys 

• Connect to the cloudflared URL and authenticate using either the provided ssh key or cloudflare access credentials 

B) Mesh VPN: Tail-scale | Head-scale

Tail-scale:  

• Signup for a tail-scale account Individual account are free, larger organizations pay per active user. See Head-scale for self-hosted alternative solution

• Download tailscale clients on your workstation and mobile devices. 

• Register your devices on tailscale admin panel 

• Connect to your devices via their name or tail-scale Ip 

Head-scale: The self-hosted alternative to the tail-scale control server

• This solution is suited for individual with interest or small organizations with the resources to configure the tailscale control server. 

• The entirety of the tail-scale stack beside the control server are open-source, allowing you to customize the network as needed. 

• Benefits: Free and opensource, highly configurable implementation of the tailscale server. 

• Drawback: May need extra tinkering to get working. 

3.2 Remote Client:

This part is very much up to user preferences, with solutions depends greatly on your choice of editor and client. I will list some potential solutions bellow for some of the most popular tool combinations: 

VSCode

• VSCode has a built in remote file editing service, which allows extensions and language servers to be installed on the host machine and stream back the output to the client machine. To use it, simply connect to the host machine as you would normally with ssh for authentication. This implementation provides 0 delay input which makes the typing experience as smooth as you would editing locally, without the lag of lsp servers and parsers slowing you down.  

Tui Editors (Vim/ nvim/ emac)

Normal old SSH and alternative SSH clients (like kitten SSH):

• The beauty of TUI applications lies in the fact that they can be used through any normal old SSH connection. Simply ssh into your workstation and open up your preferred text editor. 

Mosh:

• The SSH shell alternative that aims to fix the problem of ssh connections over spotty connection with its predictive input buffer to provide 0 lag input. 

Vim/nvim remote:

• Similar to SSH, but you control a hosted vim server on the host machine instead. Similar latency to normal SSH. 

Distant and distant.nvim: 

• WIP: Aims to provide a better alternative to regular ssh and extending on the ssh capability. Read more at https://distant.dev/about/overview/ 

• Note for TUI users: tmux is the perfect companion to be used with ssh, as it allows of mosh-like auto session reconnection and recovery. Along with the ability to swap between terminal windows without having to initiate a new SSH session. 

Other GUI Editors

• Most of these will rely on having a mounted file system from the host server to the remote client, which then allows for language servers to be run on the client and provide intelisense support. These system often have problem with parsing full project and project search. Leading to what in my experience is a rather subpar experience compared to what vscode and TUI editors provide over ssh. They are, however, perfect for editing individual small files. 

• Some GUI editor (like GUI Emacs’s Trampline) will have their own implementation of the remote file editing system. VScode’s remote server is one such case. 

3.3 Caveats

• Despite the efforts to combat input latency on remote machines, it is still unavoidable to have some action lag over spotty connections. Mosh and the vscode’s server protocols are the most adept at handling these limitations. However, if the network conditions are challenging enough, they will eventually have to backtrack and hang while waiting for resolution. 

• Using a remote workstation means you will need an always on work station or a way to recover from boot due to power outage or network delays. Having an auto jumphost server with wake on lan for workstations will be ideal for these setups. 

Conclusion

There are many ways to accommodate a remote workspace in the new world when having a dedicated workspace. As seen we have multiple ways to address those in the current environment, to find out some ways to support these approach with some other supporting work then read our blog for more useful insights about all things technical.

Hai-Anh Duong, Software Engineer