DaaS vs RDSH vs VDI

On 19 November 2012 by Pete Petersen

Desktop as a Service (DaaS), Remote Desktop Session Host (RDSH) (aka Shared Hosted Desktop, or SHD), and Virtual Desktop Infrstructure (VDI), are all valid implementations and technologies for centralizing the managed desktop of any organization. Some make better sense than others, and it may be a combination of all three that fits your organization the best.

Gabe Knuth recently wrote a piece called Three Key Considerations For Evaluating Hosted Virtual Desktops. In Gabe’s estimation, it’s not about DaaS vs RDSH vs VDI, but more about evaluating the various methods and deciding which best meet your business requirements, policies, and trust levels. In Gabe’s article, he lays out many of the challenges in actually becoming a hosting provider. All of these items mentioned in Gabe’s article were hot topics when implementing SolidCloud, Solid Instance‘s DaaS offering. Of them, some of the hottest were:

Integrating hosted virtual desktops into your environment

Internet Connection

Licensing for DaaS

The minor items that fall out of these bullets are serious, but solvable, considerations:

Going “All-In.” If you’re small or just starting an organization, this may be a good option. Especially if your vertical has no interest in doing it’s own computing technology. In this case, All-in hosting is a good option. Nothing hosted in your local sites, users fully mobile, and little or no IT staff. For everyone else, though, a mixed approach will more likely be more appropriate.

Authentication. Having the hosting provider trust your domain so that users can log into the hosted service fit most scenarios the best. As with all of these items, there are other options, such as going all-in and utilizing the hosting provider’s domain only, but that’s limiting in the fact that local resources that users need the director for are now more difficult to get authenticated to.

Host/local connectivity. Users will need to be able to connect back to data and resources that are not hosted. In this case, a bridged connection from the hosting provider’s resources back to your local resources, seem to fit the bill in most cases. The domain trust item above is a case and point. The bridge will need to always be there in order for that scenario to work properly.

Applications and application data. This is where the rubber meets the road. It is all about the applications–this is what makes the users productive–or not. Delivering applications to the users is what makes an implementation successful–or not. And application delivery scenarios, and their data, and their compute resource usage, are all wildly variable between various types of applications. Where the application runs is important, and it’s also important that where it runs is as close to the data it serves and generates as possible. Some applications, for example, use very little data, and if that data is sensitive, you may not want to let it out of your data center. In that case, hosting the application, but keeping the data makes sense. But other apps are heavy on the wire, and it may make sense for those to either have the data hosted too, or publish the application into the hosted solution.

User data. This is file data. Word and Excel data. Where this lives is also important. It’s not directly related to the profile data (next bullet), but in most scenarios, having user data–specifically the user’s home directly–and profile data, live in the same physical location–therefore hosted–seems to make most sense.

Profile data. This is the users’ settings. Where they keep their Start menu. If their email app opens to the calendar or inbox, etc. This will be part of the hosting solution, and it’s important for you to understand and query your potential provider about how they handle profile data. This will be a key indicator on how they will be able to serve your users.

PCI compliance. If you keep credit card information, then you must have a PCI policy and be able to pass a PCI audit. It’s important then that your provider and the hosting service can also pass the PCI audit with you. This is important to get out on the table up front.

Take all of these items together, and positively answered by a potential provider, you may be able to find the right provider for your business.

Trackbacks & Pings

[…] not come with. No Remote Desktop Session Hosts (or RDSH, ala Citrix XenApp or Microsoft RDS). See this post for more information on the difference between the various types of solutions. No native profile […]

It’s funny that some of the most powerful products that Microsoft produces...

VDI: The Promise and the Distant Dream

In the quest for centralization, security, control, ease-of-use, and user enablement, some of the best--and worst--implementations can be qualified by the perceived performance from the users' perspective. There is no greater importance than to deliver the applications to the users that enable them to do what they do--to be as productive and efficient as possible. Not much else matters coming out of the data center. As important as other things are; such as backup, anti-virus, redundancy, disaster planning, recovery, and even security; all are for not if the users cannot produce.

VDI is an enabling set of technologies. VDI has been around, in one form or another, since the early 1990s, developed from Terminal Services, Remote Desktop Services, application publishing, and virtual machine hosting. All of these have culminated into a set of well thought-out services that can be implemented and delivered in various ways. Many have witnessed the failure of VDI in their organizations--much of that because of forgotten components, erroneous architecture, and a steep learning curve. Contrarily, there have been outstanding and extremely successful implementations by those who thought of the core components that will make or break the solution, such as storage, profile management, image management, self-service, and simplifying the user experience from end to end. In many instances--indeed, in most instances--where VDI is new to an organization, finding the right partner--one who has been around the block before--is critical to an implementation's success.

One thing is clear: Running into a VDI implementation without first considering all of the components is a recipe for disaster. And finding the right experienced partner is key.