When we talk about VDI, we are typically describing a solution whereby a desktop PC's operating system is hosted as a virtual machine that is running on a hypervisor, with the hypervisor hosted on a server that is part of the data center infrastructure, either on-premises or cloud-based.
How does VDI work? Let's start with the end user and how they access a virtual desktop machine. From their endpoint device (a PC, thin client, or mobile device), the end user launches the client software, which is the Horizon client in the case of VMware, or they simply open a browser. Either way, this connects them to a connection broker using its hostname or URL. The job of the connection broker in the first instance is to authenticate the end user and then to manage the available resources and connect the end user to the appropriate virtual desktop. The desktop that's delivered to them could be based on their physical location or on a departmental basis where there are different desktop configurations depending on the context of that user.
The following diagram describes, at a high level, how VDI works:
In the first VDI solutions that came to market, there was no concept of a connection broker and instead, an end user would connect directly to a virtual desktop machine on a 1:1 basis. It was like picking up their desktop and moving it to the data center.
Once an end user is connected to a virtual desktop machine, the screenshots, or the display of the virtual desktop machine, are sent over the network to the client software or browser on the endpoint device using an optimized delivery protocol. To enable the end user to interact with the virtual desktop, the mouse movements and keystrokes are then sent back to the virtual desktop machine over the network via the same protocol.
Therefore, VDI desktops are more secure as no data leaves the data center, but instead, just the screenshot updates or pixel changes are sent over the network. As per the previous analogy, it's like picking up your PC and putting it in a data center that's miles away from your home and then having your keyboard, mouse, and screen at home with very long cables back to the data center.
That's VDI from a connectivity perspective, but let's focus on the virtual desktop itself for a moment and look at how the architecture differs from a desktop in the physical world. VDI desktops are typically built on demand, that is, when a user logs in and requests a desktop resource. To help manage costs, you would typically deploy a non-persistent desktop model (as discussed in Chapter 2, Understanding Horizon 7 Architecture and Components) whereby users don't own their desktop and would have a new desktop built for them each time they log in. Therein lies one of the key differences between virtual and physical desktops.
As we just discussed, a virtual desktop typically gets built on demand, bringing together the different components that make up a full desktop environment. The operating system, user profile, desktop policies, and applications are all treated as separate, individual components, abstracted from the underlying machine, and then delivered back together to create the end user's desktop experience.
This is referred to as the composite desktop model, which is shown in the following diagram:
The key take away here is that virtual desktop machines need to be treated differently from physical desktops, and to reap all the benefits that virtual desktop machines offer, they should be built from the ground up and managed as virtual machines from day one, using some of the components that have been specifically designed for the management of VDI. We will discuss this in the next chapter.
![]()
So, what are the differences between these technologies and VDI, if any at all?
SBC is a technology that has been around for some time. In fact, you could probably trace its roots back as far as the 1950s, to the mainframe technology that was designed to deliver centralized compute power to run a set of applications, with users connecting to the applications using a green-screen terminal, which was pretty much just a screen with a keyboard.
Fundamentally, SBC has not changed that much and still runs applications centrally, albeit today, it runs on servers rather than a mainframe, and end users connect using some form of end point terminal. So, in that case, it's not that different to VDI in that you are connecting remotely to applications that are running on server infrastructure hosted in the data center. Or is it?
Let's look at delivering applications first. The difference between VDI and SBC is that with SBC, the applications are installed and run on the actual servers themselves, using a multi-user version of the application to create individual application sessions for each unique end user. The end user would connect to their own individual, separate, and protected session of that application, instead of connecting to an instance of an operating system containing the applications, as they would with VDI. Since everything is running in the data center, users would connect to the session via a terminal or thin client. In fact, SBC is sometimes referred to as thin-client computing.
The following diagram provides an overview of how applications are delivered using SBC/ Remote Desktop Services (RDS):
Using the SBC model, you can also deliver hosted desktop sessions in the same way. This time, instead of connecting to a separated, protected individual application session, the user now connects to a separated, protected individual session of the server's operating system. One thing to note here is that the end user is essentially running a server-based operating system session such as Windows Server 2016, rather than a Windows 10 desktop session.
At the end of the day, which technology you choose to deploy comes down to your use case, and which technology makes the most sense from both a feature and cost perspective. You may well end up with a hybrid, with the different methods delivering desktops and applications based on different departments within your organization, all of which have distinct requirements.
![]()
By vi...
