Teradici lived in relative obscurity until late 2008 when VMware announced they were licensing Teradici's PC-over-IP (often shortened to PCoIP*) remoting protocol for inclusion in View 4.0 (which was released last November) to compete against Citrix HDX. Now that VMware's version of PCoIP has been out for a while, what's the deal with Teradici? What does their future look like as a company? Was their deal to license PCoIP to VMware the most brilliant or the most stupid thing they could do?
To understand this, we have to take a step back and look at how Teradici and PCoIP came to be.
The origins of Teradici and PCoIP
Since most people today think of "VMware View" when they think of "PCoIP," that means that most people associate PCoIP with VDI. But VDI didn't exist back in 2004 when Teradici was founded. In those days the only Windows flavors of server-based computing were Terminal Server-based solutions like Citrix MetaFrame. Of course the reasons people used Terminal Server in 2004 were very similar to the reasons people use VDI today: Management, Access, Performance, and Security. The problem back then was that many applications were not compatible with Terminal Server—both for performance reasons and for lack of multiuser support.
Even though the concept of VDI as we know it today was still a few years away, a lot was happening in 2004 that would ultimately lead to its creation. First was that the blade form-factor was starting to catch on as being more efficient and flexible than rack-mount servers, and second was that Windows XP was starting to catch on and included built-in remote desktop capabilities.
It didn't take long for people to realize they could combine the concept of server-based computing with blade servers and Windows XP to create a "blade PC" or "workstation blade." (Check out what I wrote about Blade PCs back in April 2005.) Blade PCs offered the management and security benefits of server-based computing while allowing financial and engineering users to have the power of individual workstations running apps that wouldn't work on a Terminal Server. There was even a Blade PC industry consortium and conferences dedicated to the blade PC concept.
Probably the biggest thing that sucked about blade PCs in 2004 was that the remoting protocols weren't good enough to deliver the graphical experience that customers needed (not to mention the higher resolutions and multiple displays that were working their way into the mainstream). Ironically the reason people used Blade PCs instead of Terminal Servers was often due to intense application requirements, and these were the same applications that the remoting protocols of 2004 couldn't deliver. D'oh!
So back then there was the perception of a huge opportunity for someone to come along and create an amazing remoting protocol that would rock for intense graphics. Microsoft wasn't going to do it because they hadn't yet realized that RDP could be strategic for them. Citrix wasn't going to do it because they had the Terminal Server-based MetaFrame franchise to protect and they didn't see the blade PC as being serious competition. So who did that leave? Probably the only serious effort was from HP, since as a manufacturer of both blades and thin client devices, they wanted to see workstation blade solutions succeed. HP developed their own remoting protocol called "RGS" which was aimed towards the higher-end remote graphics market. RGS was entirely software-based and worked pretty well, although it required LAN connectivity to deliver a true local-like experience.
This is the environment into which Teradici and PCoIP were born. The founders of Teradici believed in the promise of the blade PC solution, and they felt that if they could create a purpose-built protocol that's built for remoting the entire Windows desktop experience—graphics, USB, multimedia, everything—then they could have a leg-up on everyone else. Teradici also felt that only way they could get the performance they needed was to build hardware chips that would be used in pairs—one in the remote host and a second in the client device—which would handle all the encoding and decoding of their protocol.
Teradici's business model would be that they would just design and build the chips. Then they'd sell them to blade and thin client makers for inclusion in their own devices.
A lot has been written over the past six years about whether Teradici's decision to create a chip-based solution (as opposed to a software implementation) was a smart move. What's important to remember is that in 2004, Teradici designed PCoIP for blade PCs. And in a world where each user had his or her own physical blade, then adding a special chip to the host wouldn't be a problem. (The host blades used for blade PCs were already evolving to be different products than server blades. For example, workstation blades typically needed less storage and more graphics capabilities than server blades, so if a customer was going to add a PCI graphics card to a blade, then choosing one that also had a PCoIP chip in it would be no problem.)
The blade PC's future is disrupted by the hypervisor
Everyone knows how disruptive hardware virtualization was to server, storage, and OS vendors. But the hypervisor screwed up the plans of lots of little niches too, like the blade PC segment. Right as blade PCs were starting to gain some momentum and as companies were starting to solve the last problems of connection brokers and graphics remoting, VMware was offering a serious server virtualization platform as a way to consolidate and economize all those underutilized servers in the world's datacenters.
So 2006 saw the emergence of the "virtual" blade PC (a.k.a. "VDI") with all the benefits of the blade PC but with the advantages of VM-based PCs instead of blade-based PCs. For Citrix and Microsoft—who had been largely ignoring blades up to this point—this meant nothing. To VMware—who had ignored the blade PC segment—this meant a new opportunity. And for Teradici—who bet the company on blade PCs that each ran on their own physical blades—this meant some sleepless nights.
Not only had Teradici decided to build their blade PC remoting protocol solution as microchip hardware instead of software, they decided to build it with ASIC-based microchips. To most people, a chip is a chip. It's little and black with metallic legs, and if you crack it open it you'll find innards that look cool under a microscope. But not all chips are created equal. In the microchip world there are several different types of chips, two of which are the ASIC and the FPGA.
- The ASIC (which stands for "application-specific integrated circuit"), is probably what most people think of when they think of how microchips are made. A full design is created first, and then a custom chip is mass produced for that exact design. For the purposes of this story, the ASIC is 100% custom. The chip can do exactly what the designers want in any way they want, and it can get the best performance from the smallest package with the least power. The downside to the ASIC is that it's expensive to produce (due to all the testing since you don't want to find a bug in the hardware that would require a redesign) and there's a long turnaround time, typically 24 months from the time the design begins until the time the finished chips start coming off the assembly line.
- The FPGA (which stands for "field programmable gate array") is an interesting take on the chip. Since all microchips are a series of millions of very simple logic gates (made up of transistors), the FPGA is a sort of generic chip package that can act as a template which can be customized to a particular job after the chip is built. FPGA makers produce template chips with millions of gates and pathways and everything all ready to go, and then the FPGA is literally "programmed" by a customer. (Or, more appropriately, the gate design and electrical connections are "burned" into the pre-built template chip which can then act as the chip was designed). The nice thing about FPGAs is that they can be programmed quickly, so you could have engineers who finalize their designs in the morning and come back after lunch to plug their new chips into the devices for testing. (Think of an FPGA kind of like a breadboard on a chip.)
The ASIC-versus-FPGA differences can be visualized like the differences between a stamped DVD (the ASIC) and a blank burnable DVD (the FPGA). The stamped DVD is better for high-volume mass runs and can be customized for different formats and with special capabilities, but it takes a few weeks to make and has higher fixed costs. Burned DVDs can be made in just a few minutes but with less flexibility for the creator.
Teradici's PCoIP chips are ASICs, not FPGAs. This is almost certainly due the the fact that the Teradici chips are highly specialized, including USB controllers, video inputs, Ethernet controllers, firmware, audio controllers, etc., all in the single chip. It's unlikely that a single FPGA template chip exists with the right parts that could do everything that Teradici requires a the speed they need it. In many ways the specific chip architecture that Teradici chose doesn't matter, but in the context of this article it's a big deal since going the ASIC route probably adds two years to the product development lifecycle of the Teradici chip products. Then on top of that you have to keep in mind that Teradici doesn't actually build any devices—they just supply the chips. So once their chips are available they're just sent to other manufacturers who have to do all their design and testing and manufacturing, and all told Teradici is probably looking at a three-year cycle from development through shipping for products that use their hardware chips.
The PCoIP evolution
The good news for Teradici was that when the first products that incorporated PCoIP chips started appearing in the middle of 2007, people generally saw that they did what Teradici said they could do. The bad news was that by this time people were already starting to ask Teradici questions about how these chips could be used in for VDI environments. Teradici's answer? They can't.
The best Teradici could do is to say that they're working on host chips that can support multiple clients, but that wasn't revealed until late 2008 which puts that product availability back to 2011.
At this point it's easy to see how Teradici and VMware got together. On one side you have VMware, a company with a VDI solution in need of a remoting protocol, and on the other you have Teradici, a company with a remoting protocol in need of a market. At first glance it seems like a match made in heaven. But reality is a hard mistress. VMware's whole company is about diminishing the value of proprietary hardware with commodity software, and Teradici is all about using proprietary hardware to solve a problem that's approaching "solved" status with commodity software.
What could possibly go wrong with this plan? ;)
VMware + Teradici =
As I wrote in the intro to this article, VMware and Teradici teamed up in 2008 to announce that they were going to work together to build a software-only implementation of Teradici's PCoIP remoting protocol that VMware would include for free in a future version of their VDI product. From a business standpoint this makes a lot of sense. But from a technical standpoint... yikes!
Imagine the challenge of taking a remoting protocol that was designed from Day 1 to run on custom hardware and porting it over to software? Sure, they can make it "work," but will the physical server resources exposed to the VM be able to deliver the experience that PCoIP has with the chip-based solutions? Will they be able to do it without taking too many server resources which would severely impact user density? (After all, you don't want a situation where a VDI host server can run 50 users via the RDP protocol but only 25 users via PCoIP.) And finally, is the actual PCoIP protocol flexible enough to work via VDI's "new" requirements, such as via WAN connections and with the various network accelerators?
After more than a year of development, VMware shipped View 4.0 last November with the software version of PCoIP built-in. So the answer is "yes," the engineers can get the protocol to work in software. And as Gabe and I learned during our Geek Week: VDI Challenge, yes, it is possible to get the same experience with the software-based implementation of PCoIP versus the hardware-based solution. (Although for our Geek Week: VDI Challenge testing, we had zero latency, unlimited bandwidth, and just a single user on our host server.)
In the real world it seems that the software implementation of PCoIP isn't as flexible as RDP or HDX. If you do some forum searches and talk to customers who have evaluated the software PCoIP that ships with View, they report that enabling PCoIP does have an impact on user density (i.e. fewer users per server with PCoIP turned out) and that it doesn't work as well when several users share a WAN connection. (For the record, VMware responds by suggesting that it's not an Apples-to-Apples comparison, since people typically try to push PCoIP harder than RDP which leads to more intensive use resulting in fewer users per server. They also point out that while PCoIP might consume more host resources, it delivers a better experience. So if user density is more important than user experience to you, then go ahead and continue using RDP.)
It's also clear that PCoIP was never designed to be used across WAN connections. (I guess that's obvious since Teradici only released a firmware update that added WAN support a year ago.) Even so, PCoIP suffers from the fact that it's encrypted end-to-end, a nice plus for a LAN but a problem on the WAN since it means that WAN accelerators can't peek into the PCoIP packets to compress, cache, or re-prioritize specific elements. (Besides, most WAN connections are encrypted with some kind of SSL-VPN anyway; it's not like customers need that from their remote display protocol vendor.) Teradici is also UDP based into of TCP based, a characteristic that's also great for the LAN but not good for WAN scenarios. This means they can't easily incorporate the various client-side rendering components that they licensed from Wyse.
I'm not writing this to slam PCoIP or to say it's bad; I'm just pointing out that it was designed for LAN environments. (Ironically VMware's marketing department likes to say that PCoIP is the only remoting protocol that was designed from the ground-up to be a full Windows desktop remoting protocol. This statement is actually true, although if they want to talk about today's implementation versus purity of design, then they should also mention that PCoIP was designed for high-bandwidth low-latency LAN connections.)
Despite all these challenges, VMware's software implementation is about all you hear about PCoIP anymore. Sure, there are still some workstation blade solutions on the market that leverage the Teradici chips, but physical blade workstations are like physical servers—there will always be a niche, but that ship has sailed.
What does Teradici do now?
There's disagreement as to whether Teradici's decision to license PCoIP to VMware was brilliant or stupid.
Those who believe is was stupid suggest that Teradici licensed away their crown jewels, and that now that a software implementation of PCoIP is out there, the hardware business will die. When that happens, what does Teradici have? A protocol that was designed to run on hardware that now only runs as software that's controlled by someone else? Big deal!
Those who believe that Teradici's decision to license to VMware was brilliant argue that Teradici had their backs to the wall and that VMware was their best (or only?) option. By the time Teradici started shipping their chips in 2007 they were already behind the times. How could Teradici have said "no" to that licensing agreement? Add to that the fact that while VMware needed a protocol, they didn't need Teradici's protocol. VMware could have licensed RGS from HP, and there's an argument to be made that that would have been easier since RGS was already software-based and at that point had been deployed to more production seats than PCoIP.
And let's not forget the financial side of Teradici. To date they're received $63m in funding. Let's assume they sell their chips for $20 each (which is probably high). That means they have to sell 3m of them just to get the revenue back to cover the initial investment, and they have to sell 6-9 million of them to make their investors happy. And in a world that's quickly moving away from host side chips for remoting and is threatening to move away from chips for the client, that 6-9 million target looks tough. So why not leverage VMware to sell more PCoIP sockets, even if they are software? Then again, if VMware only pays half the price for a license as a chip, now Teradici needs 12-15m VMware View users to make the investors happy.
And frankly now that Wyse has announced their Wyse Zero platform with an HDX zero client for $330 (that can also do multimedia redirection by the way), how much longer can they sell the chip-based PCoIP client for $450? I would imagine that a Wyse Zero for PCoIP is around the corner, and once the software client portals catch one that will kill half of Teradici's hardware market.
So what does Teradici do now? What options do they have besides doing what they're doing? Maybe their future is hypervisor integration? Or maybe by now it doesn't even matter?
Their VMware deal is not exclusive, (although the software implementation the two companies built belongs to VMware). Does Teradici build a software implementation for someone else? Do they abandon chips altogether? Do they only focus on client-side chips? Will they exist in two years? (Or will they have been bought by VMware for an undisclosed-yet-super-cheap price?) What do you think?
*Footnote: I was contacted by Teradici's PR department recently. The requested that I shorten "PC-over-IP" to "PCoIP" instead of "PoIP." Their rationale was that PoIP is too close to VoIP. I don't see it, but whatever. If they want to be PCoIP instead of PoIP, that's fine with me. I'm happy to comply and pass it along.
(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.