When we talk about Virtual Desktop Infrastructure, (VDI ) as it's more commonly referred to, we are typically describing a solution whereby the desktop operating system is hosted as a virtual machine running on a hypervisor, which in turn is hosted on a server that is part of the data center server infrastructure.
This type of desktop virtualization is also sometimes referred to as a Hosted Virtual Desktop (HVD).
The following diagram shows a high-level view of a typical virtual desktop infrastructure:
How does it work? A user connects remotely from their end-point device (a PC, thin client terminal, or mobile device) to a connection broker. The connection broker manages the available resources and connects the user to an appropriate virtual desktop. In the first VDI solutions that came to the market, there was no concept of a connection broker, and a user would connect directly to a virtual desktop machine.
Once connected, the screenshots of the virtual desktop machine are sent over the network to the endpoint device using an optimized delivery protocol, and the mouse movements and keystrokes are sent back to the virtual desktop machine via the same protocol.
No data leaves the data center, but instead, screenshot updates (pixel changes) are sent over the network. It's like watching a smart TV with the pictures broadcast on your television from the television studios, rather than the actors performing the show in your lounge, and you interact with the TV via the remote control.
From an architectural perspective, the virtual desktop typically gets built on demand, bringing together the different components that make up a full desktop. 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 a user's desktop experience.
This is often referred to as a composite desktop and is shown in the following diagram:
You should remember that virtual desktop machines need to be treated differently to physical desktops, and to reap all the benefits of virtual desktop machines, they should be built from the ground up and managed as virtual machines, using some of the components that have been specifically designed for the management of virtual desktop infrastructure, which we will discuss in the next chapter.
VDI sometimes get confused with Server Based Computing (SBC) or Remote Desktop Services (RDS). So what are the differences between these technologies and VDI (if any)?
Let's take SBC/RDS first, as this is the technology that has probably been around the longest. In fact, you could probably trace it back as far as the 1950s, with the introduction of mainframe technology that was designed to deliver centralized computer power to run a set of applications, with users connecting to the applications using a green-screen-type terminal, which was more or less just a screen with a keyboard. This is shown in the following diagram:
SBC or RDS is seemingly not that different to VDI in the way that it works. You are remotely connecting to an application that is running on server infrastructure hosted in a data center. But that's where the similarities end.
Let's take delivering applications first. The difference is that the applications are installed and run on the actual servers themselves, and are using a multi-user version of that application to create the individual user sessions.
A user would then connect to their own individual, separate, and protected session of that application, instead of connecting to an instance of the operating system containing the applications. As 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.
Using this same model, you can also deliver hosted desktop sessions in the same way. 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. The one thing to note here is that the user is essentially running a server-based operating system session such as Windows Server 2012, rather than a Windows 10 desktop session.