In a previous article, I claimed that DDI (the Dynamic Desktop Initiative) is Citrix’ version of VDI (Virtual Desktop Infrastructure). A few people have rightly pointed out that this is not entirely true, and I want to spend a few moments to clarify how the DDI vision differs from VDI. I hope that this will also explain the relationship between Trinity and few forms of that are currently in circulation.
The major difference between DDI and VDI should be clear from the choice of terms and acronyms: while virtualization clearly plays a big role in VDI, the more generic term is used DDI. This highlights that we envisage Trinity to be a generic desktop brokering solution that is not intimately tied to a particular virtualization solution to deliver desktops as virtual machines. More specifically, VDI is of course a VMware term, hence in a strict sense a VDI solution would require desktops to execute on top of VMware Virtual Infrastructure. However, it is straightforward to generalise the concept other virtualization vendors such as Microsoft or XenSource.
Back in Trinity land however, there is no dependency on VMware or any other virtualization vendor. Instead, Trinity operates on desktops, or workstations as we prefer to call them, regardless of the underlying execution environment. Hence Trinity can just as well broker access to a rack of physical blade machines hosted in the data center, each running its own copy of the OS, or even to the PC under your desk, should the Trinity administrator decide to make it available through the broker. (If you thinking that this strays into GoToMyPC territory then you are not far off, although of course Trinity is an in-house deployment and not a service offering like the GoTo family of products.) Lastly, Trinity also offers access to a published server desktop using traditional CPS functionality as explained in my previous post. We are currently working on the right terminology to differentiate these types of desktops, and to highlight their differences in terms of and typical use cases; once this has settled down a bit, I share it on this site.
So, to come back to virtualization, and its relationship to Trinity; maybe it is best to approach this by differentiating the various types of virtualization. Unfortunately, there seem to be nearly as many definitions of virtualization around as there are vendors in the space. I try to stick to the Citrix view of virtualization here:
- Application virtualization is our term for the type of remote access offered through CPS and similar solutions (confusingly, I have also seen this referred to as desktop virtualization). Trinity complements this type of virtualization nicely: while Trinity can broker access to, and deliver a desktop, the apps that you run on the desktop may very well be delivered as virtualized applications from a remote server. Consider a typical Citrix-internal use case scenario: enterprise applications such as SAP and tools for tracking product defects are delivered through our in-house CPS farms. There is no reason why you cannot do exactly the same thing if your primary desktop has been delivered through Trinity. In fact, we are starting to investigate how we can improve the performance of virtualized application delivery in this ICA double-hop or pass-through environment.
- I have also heard application streaming – as per Citrix Tarpon or Microsoft SoftGrid – referred to as application virtualization. Regardless of terminology, again there is a fit with Trinity, since application streaming can be the perfect method for delivering applications to a desktop brokered through Trinity. Especially in an environment where desktops run as VM images, streaming applications makes image management a lot less complicated. There was a good example of application streaming used in a customer case study at VMworld 2006 -look out for the slides and podcast of session MED0062.
- Machine virtualization is the technology VMware, Microsoft, XenSource, and others use that makes physical machine resources available to multiple virtual machines. It can provide the infrastructure upon which you build a Trinity solution. Running the brokered desktops as VMs has cost and management advantages over using physical machines (that being the VDI pitch), but machine virtualization can also be used to optimize the Trinity server infrastructure. Just like we see a number of customers run CPS and other Citrix servers in virtual machines, I would expect the same to happen for Trinity servers.
So there you have it: while Trinity doesn’t depend on a particular virtualization technology or platform, it can integrate and take advantage of in several flavours of virtualization. And while Trinity is thus virtualization-agnostic, we would expect that the majority of non-server desktops brokered through Trinity will be running as VMs, for the aforementioned cost and manageability reasons. As for the Trinity team, this means that we will strive to provide the required integration between Trinity and popular virtualization platforms to ensure that you can manage both the brokering and machine virtualization aspects of a Trinity deployment smoothly and efficiently.
Finally, a brief update on what’s been happening in the team: we are now busy designing and prototyping the major building blocks for the second Trinity release targeted for late next year. We are taking advantage of some the newer technologies such as WCF, to reduce the time spent prototyping, and in a recent demo I have seen the first direct ICA connection to Windows XP running within a VM. In reality, this was missing a lot of the required server-side infrastructure, but it was a cool demo and by the way, in case you missed it: Citrix has just bought Ardence (Brian Madden has a good overview of their technology and some of its benefits in a CPS environment – and as you would expect he has already posted his analysis of this announcment). Now we can start planning in more detail how this will play with our Trinity designs. More on this, I hope, after the Christmas break.
Note: I hand-edited this post since it seems to have been badly garbled during the transition to our new blogging platform. I haven’t materially altered its content though (although some parts of it are now a bit out of date).