Home > The Hybrid Workstation
Michel Perfetti
14 June 2022
Lire cet article en Français

The Hybrid Workstation

Hybrid workstation

Today, as part of our hybridization content, we’re going to look at the hybrid workstation. The hybrid workstation uses technologies like containers and the cloud to extend the workstation and provide project environments on demand without affecting the local workstation configuration. In particular, we have a demo on how to use VSCode to show how easy it is to work this way. All the tools are readily available.


Workstation Inventory


Even though we’ve largely succeeded in managing the configuration of our production environments, the design of the developer’s workstation is still a major issue.

By its nature, the workstation is complex to maintain:

  • OS updates
  • Updates (or not) to development tools
  • Demand for services, e.g., databases
  • Incompatible versions of some software, depending on the project

Then, each developer has to switch between the different versions and know when to update to ensure a compatible working environment for all the projects they work on.

These individual decisions affect the team’s development process and can occasionally lead to minor version changes, causing major behavioral shifts. Ultimately, you end up with a team where each member has a unique configuration, a far cry from the controlled production versions.

All types of projects are affected, from development projects to cloud infrastructure projects, when the new guy on the team updates the Terraform states to a newer version than the one the team decided on so no one can deploy it (we’ve been there!).

There is a theory that the problem stems from the fact that we are administrators of our own workstations. I disagree. Without this, we would be stuck with out-of-date versions of our tools, with no ability to update them across the team.

As we said at the start of this post, we have been able to solve this problem over time in our production environments. The most advanced version is currently the container, which combines our business code and its environment. Let’s look at how we might use this on our workstation.


Container and Workstation


You’ll need the following to partially recreate some of the demos:

  • a computer, regardless of its OS
  • Docker installed
  • Visual Studio Code and the remote extensions

Clearly, the configuration is pretty simple. In addition, VSCode automatically updates everything. The other benefit of the container is that it doesn’t matter what operating system is on the workstation as long as the development tools are there.

I start by opening VSCode in an empty folder. Next, I tell VSCode to create a container for this folder. The VSCode documentation is clear enough to start from scratch, but it also comes with some ready-made templates that we don’t mind using.


VSCode création conteneur


I’m going to choose the .net/C# development option, but C# only. Other images are available with SQL Server or PostgreSQL. These images are supported in VSCode thanks to Docker Compose. The development environment has other services running in different containers in our particular scenario. It is possible to simulate an entire application ecosystem on your computer without installing a server. We’ll come back to this at the end of the post.

I now have to choose the version of.net and any other components in the configuration.


choix de version et composants de V.net



Let’s look at what VSCode has given us:




A .devcontainer folder has been added. It contains the settings for both the image and VSCode. VSCode’s behavior can be changed to fit the image, such as by defining a list of required extensions. Here, in the list of extensions, we can see that there is one for C#:


Extensions VSCode


This ensures that your project also has all the tools (VSCode extensions) your team needs to work.

Once the container is up and running, you can open a command prompt and create your project. For the demo, we’ll create a simple console:

dotnet new console -n demo


Work on the Web


VSCode also has the advantage of being able to run in a browser. Let’s upload our project to GitHub. If you have the ability to create codespace environments, this is what you will see:


VScode navigateur web


Once it’s loaded, we can use a browser to access a full working environment, including the same integrated development environment (IDE) and extensions. GitHub has provisioned a machine for us.


GitHub VScode


GitHub manages the container in this mode, even down to the IDE. No local configuration is required. This mode can also be used on our workstation with VSCode:


GitHub mode avec un VSCode sur notre poste de travail :


A number of other software platforms besides GitHub also allow this type of functionality. Gitpod, a remote development environment specialist, and the Space & Gateway tools from Jetbrains are alternative options.

With the new Gateway product, Space and Gitpod users can now easily create a virtualized work environment that can be used with tools like Intellij, Rider, and more. The same thing can be done with a local container, but it takes a little more work and a specific configuration (Java and Secure Shell (SSH) server, among others).


A Full Working Environment, Including Services


When I created a working environment at the beginning of this post, I had the option of choosing either SQL Server or PostgreSQL. This is what happens most of the time: the application needs dependencies like database services to work. Having these services available, locally or remotely, is part of configuring your workstation.

Let’s create a C# project with SQL Server. The .devcontainer folder has an additional file: the docker-compose.yml file.


Workspace docker dec container


Docker uses this file to describe all the containers it needs to create its environment. Here, there are two: “app,” for development, and “db,” for the database:


Docker compose


We can see the two containers in the Docker console:


console docker conteneurs



Through the use of “forwarded ports,” it is possible to establish a direct connection between the tools installed on the workstation and the containers, allowing for direct interaction with these services.


Containers as an Alternative to the Local Work Environment


Containers are a viable alternative to the local work environment, but they must be supported by development tools. This is more complex with languages that need advanced IDEs because they may not yet support this kind of environment. In all other cases, if VSCode is your preferred IDE, it is just as natural to work this way as on your workstation directly. Some operations take a little longer, but the centralized configuration has a lot of other benefits that make up for this.

Would you like to know more about hybridization? See all our posts on the subject:

This posts should interest you
Leave a Reply

Receive the best of Cloud, DevOps and IT news.
Receive the best of Cloud, DevOps and IT news.