by
Brian Madden
Last week Wyse made a pair of announcements around their evolving “zero client” portfolio. First, they announced a new platform called Wyse Zero that will be the foundation for multiple types of zero clients. (In Wyse-speak, the Wyse Zero platform would work with a number of different protocol “engines.”) Second, Wyse announced that the first client device built on the Wyse Zero platform will be an HDX engine called “Xenith” that will be a zero client for Citrix XenDesktop.
This is an interesting announcement from Wyse and probably a glimpse of what client devices will look like in the future, so it’s worth exploring what zero clients are and how Wyse is approaching this space.
What is a zero client?
A zero client is like a thin client, but with less to manage and maintain on the client device itself. (So it’s thinner than thin—a “zero,” if you will.) The zero concept is a result of the “thin client bloat” over the past 15 years that led to thin clients slowly and steadily becoming more complex until today they’re essentially the same thing as a small form factor PC with a thin client OS. This is a problem because thin clients are supposed to be stateless, yet IT pros spend a lot of time managing, configuring, patching, and updating these things. (So yeah, they’re “stateless” in that they don’t usually have any real data on them, but they make up for it in configuration!)
Eventually people said, “Enough with this thin client management. Let’s go back to the basics and stop wasting time managing thin clients!” (I like to point out that I’ve been saying this since 2005, but who’s counting. ;)
The exact definition of a zero client—like all trendy things in the world of IT—varies depending on who you ask. Some claim that a zero client can’t have any software on it at all, while others claim it can have software as long as it’s stateless (i.e. no device management or patching), while still others don’t mind stateful firmware as long as the device doesn’t have any public interfaces. (And of course, each vendor defines “zero client” in a way that just so happens to describes their own products. :)
There are a lot of folks claiming to have zero clients on the market today, including:
- Sun / Oracle, because the Sun Ray thin client just does a simple network boot and dynamically streams its OS from a Sun Ray server
- Teradici, via their PC-over-IP (PoIP) hardware client partners, like Wyse, 10Zig, Devon IT, Dell, etc.
- Pano Logic, whose Pano cubes have no firmware, no CPU, and no memory
- And now Wyse, whose Wyse Zero clients download all of their configuration information and OS from a server at boot time
When a Wyse Zero client (like the new Wyse Xenith product) powers-on, it does a DHCP boot and reads an extended option flag from the DHCP server to learn where on the network its configuration is stored. The client then downloads a config file which tells it how it should operate and where its OS (err, “engine”) binaries are stored. In the case of Xenith, that’s a <4mb HDX engine which is either downloaded on the spot or booted from cache. The user is then presented with a login box and off they go. This entire process (from cold boot to login) can happen in a matter of seconds.
So to be clear, a Wyse Zero client such as the Wyse Xenith actually downloads its configuration information and core engine from the network. Is that zero? By Wyse’s definition, yes. They call it zero because no configuration needs to persist on the client (it merely caches the engine for boot speed convenience). In some ways this is like the difference between the old Full Program Neighborhood Citrix client and the Program Neighborhood Agent—the agent was a sort of “zero” client because it pulled all of its configuration from an XML file on a web server. (Although I guess in that case the user still had to manage all of the binaries.)
Do I think this is a zero client? I guess first I should point out that it doesn’t *really* matter how the executing code gets on to the client device. If a device exists with no local configuration then I’m going to call it a zero client, period. (Ironically by that logic, a Pano cube and a Sun Ray are both zero clients, but a Teradici PoIP hardware client is not since it has old-school firmware which must be updated from time-to-time.) And again, this is really a game of semantics, because you could argue that even Pano has “code” that runs on its client device since you could (in theory) reprogram the FPGA the device is based on to change how it works.
The bigger point is that it doesn’t matter how “zero” any of these things are. What matters is that the various zero clients are easier to manage than more traditional thin clients.
Why did Wyse create the Wyse Zero platform?
The Wyse Zero platform represents the future of Wyse’s thin clients. They made it clear (via strong hints and winks) that they could create different engines for Wyse zero based on PC-over-IP, RemoteFX, WinCE, or even ThinOS in the future. The more traditional-style thin clients will be relegated to the uses where users need local processing (local web browsers, etc.) or more than one protocol and will probably become indistinguishable from “real” computers running a thin client OS. (Hey, Wyse just happened to announce the “Wyse PC Extender” last week too! Coincidence? Here’s a glimpse of the future for you: It’s 2015. Is there a difference between a Wyse thin client running ThinOS and a small form factor full PC running Wyse PC Extender? Twenty bucks says you'll just have that and Wyse Zero.) Future zero engines could be delivered from the cloud, internal servers, etc.
So it’s in Wyse’s interest to have the Zero platform and this will be a big part of the future of the company. But for today, the real winner with Wyse Zero is Citrix and the fact that the first implementation of Wyse Zero is an HDX engine for XenDesktop. The VMware sales channel was doing a great job selling the “simplicity” of the View PC-over-IP hardware zero clients against Citrix HDX which required a full and complex stack. And then with Microsoft announcing RemoteFX and the various zero client options around it, Citrix suddenly found themselves as the only major desktop virtualization platform without a zero client story.
So while I’m sure Wyse didn’t run out and create Wyse Zero just for Citrix, I’m also sure it was a no-brainer that XenDesktop HDX would be the first implementation of it.
Digging into Wyse Xenith and the Wyse Zero platform
Remember that Wyse Xenith the product name for the zero client for XenDesktop and HDX—it’s the first product built on the new Wyse Zero platform. The Xenith device is actually the same hardware as a regular Wyse C class thin client device. The only exception is that the firmware of the Xenith is built to look for an HDX engine configuration file instead of running ThinOS or Windows CE locally.
What’s interesting though is that Wyse C class devices and Wyse Xenith devices are NOT interchangeable or inter-compatible. If you bought a ThinOS or WinCE C class, it will always be a C class and never a Xenith. “Ok,” I thought, “that’s because the Wyse Zero engine and a local OS are two different things.” But what about future Wyse Zero engines? Do they envision being able to convert a Wyse Xenith into whatever the Wyse Zero engine version of RemoteFX is? The answer is no. Even though these things share the same hardware platform, Wyse’s view right now is that a customer is going to buy a zero client for a specific technology.
What about these new software-based zero clients built on the Wyse Zero platform versus the more traditional hardware-based zero clients? For example, if Wyse creates a PoIP-based Zero (capital “Z”) soft client, why would someone buy that instead of the current P20 chip-based PoIP zero client? That’s an interesting scenario. On one hand, the current Wyse Xenith (for HDX) zero clients start at $330, while the cheapest P20 (for PC-over-IP) is about $450. So it would be interesting to compare the performance of a software PoIP zero client to a hardware PoIP zero client. Then again, we don’t know how much of that $450 for the hardware client is licensing fees going to VMware and/or Teradici. It’s possible that licensing the software PoIP client for a software PoIP Wyse Zero engine would be cheaper.
The ultimate irony, though, is that the Wyse Zero PoIP software client would actually more "zero" than the hardware PoIP client, since the zero software client truly has no local configuration or management at all, while the PoIP hardware clients require firmware updates that must be pushed out to each device.
There's also an interesting conversation to be had around Microsoft's RemoteFX-based client devices. It's very possible that Wyse could release a Wyse Zero-based RemoteFX client that did the RemoteFX decoding in a software engine. In this case it's likely that the Wyse Zero software version would be more expensive than a RemoteFX thin client since it's Microsoft's stated goal for the hardware-based RemoteFX thin clients to be super cheap, perhaps less than $100. (And I think this is what we'll see in future Wyse E class devices.) Of course on the other hand, the Wyse C class devices on which Wyse Zero is based probably have more power than the $100 RemoteFX clients, so you might see a Wyse Zero RemoteFX option that could support dual 1920x1200 displays, etc.
The point is that the specific protocol technology might dictate how the pricing works out for a Wyse Zero software-based versus a "real" hardware-based zero client. (And of course Wyse can play both sides and make both types of products, especially since it looks like all Zero software clients will share the same C class hardware platform.)
Regardless of how this all shakes out, I think we can all agree that these are some (unexpectedly) interesting times in the thin client device space. Tomorrow I'll follow up with a deeper technical analysis of the Wyse Zero platform and the Wyse Xenith product. Until then, what do you think? Is this a good move for Wyse? Is this the future of thin clients? How will the competition respond?
(Note: You must be logged in to post a comment.)
If you log in and nothing happens, delete your cookies from BrianMadden.com and try again. Sorry about that, but we had to make a one-time change to the cookie path when we migrated web servers.