First Steps Into A Remote Development Environment

When we were setting up our test lab, one of my primary objectives was to eventually build an Internal Developer Platform, where we simplify the process of bootstrapping developer environments through templates and automation and ultimately allow our developers to start coding minutes from signing in.

A couple of days ago, we took an important step towards making this a reality when I dragged in some of our developers into testing out Coder.com.

The first time I read about Coder, it really looked promising. Here was a platform where you could define templates for development experiences (say a dedicated template for Java and another one for NodeJS) that come complete with all the necessary tools for that particular stack, and the ability for individuals to spin up workspaces based on that template. All the code and resources would reside and be executed on the server, where we can control access and security. Developers only need to bring in minimal client hardware, consisting of a browser, an IDE and plugins to establish secure connection to the Coder service.

So we began to create a simple Coder deployment to test out how well it works in reality. At the highest level, our deployment looks like this:

A Coder server deployment is obviously necessary. This was built by just running a docker compose file that we ran on Portainer. We can figure out a more complex helm-based deployment later.

I really liked the fact that Coder supports OIDC integration with Keycloak at its free beer tier. Most open source projects with premium tiers would reserve SSO functionality only for paying customers and I think Coder's decision to support OIDC here is a fantastic move for growing adoption.

Actual developer environments would be spun up as Kubernetes deployments with persistent volumes created for each workspace on top of Longhorn. This is ideal as I envision workspaces to be ephemeral in nature. While we do need the persistent storage in Longhorn so that developers do not run the risk of losing their work just because of a pod being relocated to a different node, I do not intend for developers to treat this as another online cloud storage. Our developers move from project to project and they should have the flexibility to spin up new development environments as and when new requirements / projects arrive. You start up a new workspace, you clone a Git repository, you code, you push, you're done.

Which is why the workspace template is a critical piece of this solution. Workspaces are the very environment that developers will work in on Coder. It cannot be so basic that when a developer spins up a new workspace, he/she takes a whole days or more to set it up to be productive. Templates are essentially Terraform templates that you can customize to fit in all the tooling necessary so that when the developer spins up a workspace from it, he/she immediately feels at $HOME.

As our first template, we created a Java 21 development environment, complete with Git, Maven, Gradle and of course OpenJDK 21.

I took it for a test drive by creating workspace and cloning one of our projects into it. This was a JMix project that we were developing as a POC. I'm not the developer so I had no idea how to actually test the project, but I wanted to at least know if I was able to build the project with minimal effort / knowledge.

Creating a workspace brings you a form where you need to fill up some basic requirements on the resources you need for the environment. For a Java-based project, I found that 4 CPUs and 4 GBs of RAM is required:

After creating the workspace, you get a very minimalist summary of the workspace and what you can do with it.

The 3 buttons you see there is where the money's at. You can run a terminal window from it as a browser pop-up. You can also run an entire browser-based version of VS Code on it. But clicking on the "VS Code Desktop" button transforms the experience entirely. It opens up VS Code on your local machine (assuming that you've installed VS Code, obviously), prompts you to install Coder plugins if not done yet and then connects VS Code to the Coder server.

Once connected, it just looks like you're developing on a local environment, but all the files you're working on is actually pointing to a remote mount that is completely on the server.

For those who use IntelliJ as their IDE of choice, the ability to connect to remote development environments is unfortunately only available for their paid versions (boo, JetBrains).

I'll leave the actual coding part to my developer, but next I wanted to see if the project can build in the workspace I just created:

And waddaya know, building the project went without a hitch. Build times are not that bad either. With the Gradle daemon already running, a typical build took about slightly over a minute, which is a LOT faster than the one hour build on our developers' laptops crippled by over-aggressive anti-malware and DLP software.

At this point, I'm still giving time to our developers to properly kick the wheels on this solution. But I do like what I've seen so far and I'm hopeful that we can turn this into a standard development approach for more of our projects in the near future.

Many thanks to Aphiphit Thammarcheep for his help in setting up our templates and integration to Kubernetes.