Perspective - The fundamental flaws of thin clients

by Jeroen van de Kamp

Sorry, I have to get this of my chest. As you might suspect after reading the not-so-subtle title, there is something fundamentally wrong with thin clients.

Let me be specific here: I am NOT talking about good old trusty SBC (Terminal Server/XenApp) or the hot and sexy VDI as a concept. I'm talking about the actual "desktop appliance" or "access point" or "thin client" itself.

This discussion is not new, but now that VDI has made hosted desktops an attractive option again, there's a sort of revival of thin clients in our market space.

Thin clients can be discussed from two angles:

First, there is the typical Citrix user who's been doing SBC for years already and has been pretty successful with it.
Second, there are the organizations venturing into the VDI space who are interested in the power, manageability, and cost advantages of thin clients.
From either perspective (both SBC and VDI), that the only logical choice for the thin clients is not to use typical thin client solutions, whether Linux, Windows CE or Windows XP embedded.

To understand that logic, let's look at the constants we need to deal with in the context of thin-clients:

1. Organizations are required to build a mature and fully automated management infrastructure for PCs and laptops, even when 90% of the clients are “thin.”

The majority of distributed organizations with 1000 desktops or more are often required to support conventional PCs (for rich media editing, 2D/3D design, etc...) and laptops (mobility). This is today’s reality of Enterprise IT. Deploying 100% thin clients is still not feasible in the typical heterogeneous IT environment, even if you're considering all innovations we currently see in remoting protocols from all major vendors.

The problem is that it's not economic to neglect the management aspect of the remaining 10% (or whatever) of devices that are laptops or PCs. You can't ignore patching them just because they're the minority. And manual configuration of PCs and laptops is just too costly in distributed environments, even if you perform only one change every year. So this means that unless you can go 100% thin clients (which I don't think you can), then you have to build a management system for your non-thin clients.

The good news is PC management has matured considerably over the past few years. Building an effective management solution for laptops and PCs is not rocket science anymore.

And by the way, BYOL (Bring your own laptop) doesn't this fix this problem. BYOL is a cool concept, but the majority of organizations still require full management of the desktop/laptop for practical, legal, or security reasons. In most cases BYOL is not an option.

2. When it comes to the support of innovation and new features within remoting protocols such as RDP and ICA (HDX), traditional Windows (XP+) is, by a big margin, the best platform to choose.

All the cool features, especially those which require client-side rendering, are first developed for Windows. Quite often such innovations demand the availability of CODECs, the .NET framework, WPF, the Windows USB or printer driver architecture, and more.

The fact is that Linux or Windows CE as a thin client OS seriously lacks the rich media and user experience optimization support we see being developed first for the Windows client. This is relevant because any user experience- and performance-related innovations are very important to our end users and ultimately, the acceptance of any SBC and VDI solution.

3. A thin client is not a “fire and forget” solution. Thin clients require a mature deployment and management infrastructure.

Don’t believe me? Talk to all the IT admins who've been supporting thin client for years. They'll tell you from experience that a management infrastructure is required to deploy security fixes, client/application upgrades, root certificates, firmware updates, and configuration changes. Those who don’t probably have a very static IT environment.

In comparison to conventional fat clients, the rate of changes and updates on thin clients is considerably lower. However, one single update already justifies the investment in a management infrastructure, as manual configuration of all your thin-clients is extremely expensive.

The reality of thin devices, regardless of protocol, and even hardware embedded solutions (e.g. “PC-over-IP” devices), is that you need to be able to centrally manage and update them. The minute a bug is discovered, a security fix is required or a configuration change is needed--you need a management infrastructure where you can automate such changes.

Read rest of article