According to Microsoft documentation, Windows LAPS (Windows Local Administrator Password Solution) is “a Windows feature that automatically manages and backs...
14 June 2022
Lire cet article en Français
The 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.
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.
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#:
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:
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 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:
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.
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:
We can see the two containers in the Docker console:
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:
