Blog posts tagged with 'trinity'

If you have followed recent Citrix announcements and a number of blogs and other postings, you probably already know that we are working on a product line in the Desktop Infrastructure (VDI) space, codenamed Trinity (by the way, Dynamic Desktop Initiative or DDI, is Citrix name for VDI). As the product architect assigned to Trinity, I intend to post here occasionally to keep you up to date on our plans and progress. As always with this type of blog, please note that much of this information is about work in progress, and I certainly cannot commit to dates or promise that certain features will make it into a final product.

With that out of the way, I would like to devote this first post to a brief overview of where and how Trinity originated, and then talk about the first couple of deliverables in the Trinity product line. Some topics I had in mind for future postings include thoughts and impressions from VMworld 2006, which I attended last month, my view on where we are as an industry with VDI, and a more detailed dissection of the various types of virtualization that are part of, or relate to Trinity. Do let me know if there are any topics you are particularly interested in, and I will try to cover them if I can.

Trinity did not just start out of the blue recently at Citrix; in some form or fashion, its roots reach all the way back to 2003, when product idea #408, on demand access to desktops was submitted. In fact it is quite likely that ideas in this area had been floating around well before that submission. The gist of that product idea pretty much covers what subsequently became known as VDI. Oh, and by the way, we are up to product idea #2098 in the meantime.

In any case, some initial investigation efforts were kicked off in our Products group, and I remember a presentation that Richard Mazzaferri and Anatoliy Panasyuk gave to the UK engineering team, outlining the concepts of brokered access to virtual desktops. This sparked quite a few I like one of them, please comments from our development team.

I do not have much visibility on what happened subsequently, except that there was never really any resource available to work on it in more detail, until things started to bubble up again early this year, which was also when Trinity was coined as a project name. After a more detailed architecture and design had been worked out, there was a bit of to-and-from between the various engineering sites in Citrix, until eventually we ended up with engineering resource being provided in both the Sydney and the Chalfont sites.

Now to complicate matters a bit, there is a second strand to the Trinity lineage, which has also been going for some time, originating from the project Dart (which was never released but influenced a number of other Citrix products such as Access Essentials, or the Access Management Console but I digress). After several iterations, this culminated in the Remote Desktop Broker (RDB) for Presentation Server, which was released earlier this year as the first Citrix DDI deliverable. You can read all about RDB in a FAQ on the Citrix web site, but in a nutshell it allows you to publish an RDP proxy component on a Presentation Server, which will route the connecting user to their virtual desktop based on a configuration of virtual desktop pools that an administrator controls through a management GUI.

All this begs the question, how all these things fit together, and what we are planning for the next couple of Trinity releases. Assuming that you have a basic understanding of Remote Desktop Broker, this can be summarized as:

We target a first release of Trinity for the first half of next year, based on Remote Desktop Broker that you have already seen. It will build on the existing combination of CPS + RDB but re-engineered to deliver an integrated product and improve the administrative experience by delivering consistent access to both shared and dedicated desktops. Maybe a word about nomenclature here: shared desktops are what you are already used to from CPS published desktop feature, while dedicated desktops are single-user OSes, whether they run on physical hardware or as a virtual machine image. Terminology hasn't been finalized yet, though. We are also working on a simpler licensing scheme for this release of Trinity, but details are still being finalized.

In the meantime, we are working on the second release, which is currently slated for release in the second half of next year. This is when we will integrate PortICA, and thus deliver the benefits of ICA that can get lost in RDB double-hop solution. While the ICA stack for dedicated desktops will certainly be big news for this release, we are also planning to take advantage of the server-side infrastructure that we built for Presentation Server to bring you an integrated, seamless experience for both administrators and end users. Our goal is to make it as simple as possible for end users to access their desktop, building upon the existing application delivery infrastructure, i.e. Web Interface, PNAgent and the like. On the other hand, administrators will be able to benefit from the same tools and features that they are used to from Presentation Server.

So much for the marketing piece - I'll flesh out our current plans for the second Trinity release in a bit more technical detail in a future post, but until then I be interested to hear your views on Trinity, VDI, DDI, RDB, or any other three-letter acronym.

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).

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).