utopia or working reality of a developer

Introduction

To understand a product better, you need to use it. Sounds logical. But there are situations when the product you are developing defines your interaction with development tools. That is, it literally delivers your workspace from a remote machine to your local computer.

Can the format of workplace delivery in the form of Termidesk VDI be a working solution for development? In this article we will figure out whether this is a utopia or a very pleasant reality.

By the way, this article continues the topic started here.

In this part, I will tell you about the technologies we use in the process of creating Termidesk, and also share my experience of getting out of funny work situations using three cases as an example. For example, what do we do if the Internet is lost while working via VRM (virtual work place). Or how things are with delays when typing from the keyboard.

But the most important thing is that I will clearly show what real interaction with a virtual workplace looks like when using the domestic VDI ​​solution Termidesk.

Technologies we use

Both in the product itself and in the development process, we deal with a wide variety of technologies and tools. Among them are Python, GitLab, Ansible, Docker, Terraform, D-Bus and WMI, PostgreSQL, PyCharm, as well as various software for local virtualization.

In our work, we regularly encounter challenges that we can't just Google. Sometimes we become those who leave the only answer in the comments on StackOverflow to a seemingly long-forgotten and hopeless question about the problem of multi-monitor mode for the RDP protocol (you haven't heard about it before either?). Looking a little ahead, this is the protocol I will use as a transport in all demonstrations.

We also cannot do without classic approaches to debugging during the development process. It is normal for us to use the available IDE capabilities to the maximum: linters, fine-tuning for our project with Sources Root and Resource Root directory markup, project synchronization and debugging using RemoteSSH.

Moreover, some capabilities are simply not enough. For example, RemoteSSH in PyCharm, which still does not support working with Windows, and we have multiplatform components. The same session agent, which works not only on Astra Linux, but also on Windows OS.

How using Termidesk in our work helps us make it better

Case Study 1: Remote Development Stand

We use the method when, as a system administrator, I carry out the full cycle of Termidesk development and configuration. Most often, we use the Termidesk infrastructure for development and conducting various experiments.

The stand looks like a bundle of several remote machines, to each of which we connect:

• Termidesk dispatcher on a machine with Astra Linux;

• Astra Linux or Windows Server as the target OS, to which we connect via the Termidesk client;

• Termidesk client on a machine with Astra Linux.

Along with PC SV “Brest” and VMmanager, we use oVirt to deploy such a configuration.

During the development process, this approach gives us a number of advantages:

1. Any colleague will have access to all the machines and will be able to easily join the research on the task for which the stand was deployed.

2. The stand's capacity is sufficient to continuously support, allocate resources, clone and take snapshots of virtual machines. Even a very powerful work computer cannot always provide this.

3. It's easy to leave behind useful artifacts after work in the form of golden OS images or pre-prepared configurations that can be useful not only to me, but also to the guys I work with.

Of course, this approach has its downsides:

1. Regular simple tasks. If you need to work with only one virtual machine, constantly recreate it and perform many administrative actions with it, then this is usually slower than the same on the resources of the working computer. This happens due to the peculiarities of the virtualization platform, which processes requests in turn and not always instantly.

2. Network dependency. For obvious reasons, working with virtual machines on a cloud platform is difficult if the Internet is slow or the network is unstable.

This approach pays off when we finish working on another improvement and, for testing purposes, go through the entire process of installing and configuring Termidesk in the same way that the administrator does it in the end. This makes it easier for us to identify growth points for the product. And even if they are beyond the responsibility of our department, we can still pass the information on to key colleagues, which allows us to develop Termidesk from different angles.

For example, this was the case with logging. When we once encountered high memory consumption and duplicate entries in the log, we paid attention to it. The problem was fixed and included in release 5.0.

Case Study 2: Delivery of the Main Development Environment – VS Code

The next case is application delivery. Usually for me it is VS Code, through which development is also carried out. Although in fact it is not so important, any installed application can be delivered.

What benefit does such a scenario provide for development?

Very often we need to test some hypothesis. It is convenient to be able to quickly operate with several variants of changes to the project's source code. It is even better when you can run several copies of the project simultaneously. So that you can work with the source code of each on the fly.

And you can compare the behavior either through the host browser, or in the same way get the required number of Termidesk client applications – it depends on the task.

In practice, such scenarios are most conveniently reproduced by delivering only the IDE application. Requesting a full desktop for this would be redundant and less convenient.

Case Study 3: Fully Virtual Workplace

And now the most interesting case, about which you may have the most questions.

What if you move all development to a remote machine and work entirely through Termidesk VDI?

Workflows are a rather sensitive area for a developer. Spontaneous session breaks or significant response delays while working with code are unacceptable here.

Let's split this case into two typical development processes: typing in an IDE and switching between multiple applications in real time.

Entering text in the IDE

So, how much of a delay do you feel when working in this format? Of course, there is one compared to printing in the local version of VS Code. But if we talk about the subjective feeling while working, the delay between pressing a key and its display on the remote machine is so minimal that it does not cause any discomfort at all. After about 10-15 minutes, you don’t even notice that you are using VDI for work.

It is worth noting that in the demonstration, for the sake of fairness and purity of the experiment, I used public Wi-Fi, which does not differ in speed and ping indicators.

Multitasking

But in terms of multitasking, the effects of rendering windows at 1920 x 1200 resolution were sometimes quite noticeable. Considering the quality of the Internet connection on which the experiment was conducted, working in multitasking mode feels quite normal, although not as ideal as we would like after switching from a local workstation. Colleagues from a related department are already working on a similar task – normalizing the bandwidth when using the TERA protocol, for more details see our help center.

Bonus Track: Internet Connection Lost

Working on Termidesk is closely related to virtualization and networking. But what happens when for some reason the connection is broken and the remote session is unexpectedly interrupted?

Although for me personally such scenarios are practically excluded: if something happens to my Wi-Fi, I can almost immediately switch to a mobile hotspot – the network speed is not inferior to a home router:

In turn, the Termidesk client will automatically restore the connection after a break.

But even so, I configure Termidesk so that my workspace is not deleted when the session is disconnected:

Even in a situation of complete loss of network access, work can be continued, but on other tasks that can be performed offline. Synchronization of work results after restoring network access occurs in the classic way – via git.

Conclusion

So, is there a place for VDI in a developer's work? Definitely yes.

Of course, this format of work is not without its drawbacks, but the examples we have considered often show that the choice is justified. Especially when it comes to work that involves virtualization and multiple instances of the operating system.

Working in VDI format is sensitive to both the quality of the connection and, obviously, to the delivery protocol used.

This format of using the product that I just described definitely yields results. Including for corporate clients who need the most secure solution. It is simply important for us to look to the future in order to implement the latest solutions today. From transport protocols to a complete ecosystem of products.

In the next article, I will do a more detailed comparison of the main delivery protocols. One of the key questions I will be trying to answer is how to get the most out of your network connection and provide a better experience on a remote machine?