It’s true. In 1999 I invented DaaS, I just didn’t know it! I doubt I was alone, all through the late 90s and early 2000’s companies were trying and for the most part failing to do hosted desktops for various customers and use cases. I worked for a software company with a VERY fat application and we had the idea to provide remote desktops with MetaFrame 1.8 for our healthcare customers. To put it mildly it was a total flop. Surprisingly (or perhaps not) 15 years later the same stumbling blocks we faced then are still around… bandwidth/latency and licensing.
Today’s bandwidth concerns are a far cry from my days administering US Robotics 28.8 modem banks. The old standard line that ICA was tuned for 18Kbps hasn’t been true probably since the release of MetaFrame XP. As architects and administrators we are faced with graphics hungry applications everywhere our users go and all of those frames have to somehow be pushed to the endpoint device. Compressed? Absolutely. Re-encoded? Maybe. Efficient? Not usually. And it’s only going to get worse not better. We live in a media streaming world and users expect that their VM, be it in the cloud or in your server closet, will keep up. Given the routing challenges we face with data that is often a rather tall order.
Picture this scenario:
User Bob is working from home for the Acme Widget Corporation. Bob lives in Omaha, NE but Acme’s primary datacenter is in Atlanta. Normally Bob’s virtual desktop along with his apps and data would be in the Atlanta datacenter. But Acme management has embraced the Cloud! They went with a DaaS provider hosted out of New York. So Bob’s endpoint is Omaha, his primary connection is a VPN to Atlanta, his virtual desktop is in New York, his apps and data are back in Atlanta… Poor Bob’s data path looks like it is bouncing all over the country! Start praying he doesn’t want to do a streaming video within that session.
And that’s the bandwidth/latency challenge we face with DaaS. Can you design around it? To an extent, sure. Bob could connect directly to New York. His data could be local to his VDI. But then you are putting more services and data into your service provider’s premises. Depending on your corporate security policies that may not be an acceptable choice. And if you don’t fix it, Bob’s experience is probably going to be sub-standard at best.
The other big challenge we faced way back in 1999 was licensing. Traditional licensing structures were simply not compatible with the idea of hosting remote desktops for users you did not employ. It proved to be an insurmountable barrier and, ultimately, was probably the primary driver that led us to abandon our pre-DaaS dreams.
DaaS providers today are under very strict rules around the type of environments they can provide. The Service Provider License Agreement (SPLA) limits them to only using Windows Server desktops and their OS and Bring Your Own License (BYOL) agreements are very tightly controlled in terms of hardware and user segregation. However, the fact that DaaS is now being considered in licensing agreements is a big step forward.
Times have changed and DaaS is a buzzword across the industry. Boy do I wish I had trademarked it! In my presentation “SYN118 – Desktop as a service: perils and payoffs of an outsourced infrastructure” I will be covering these topics in more depth as well as the successes and challenges of Aetna’s 15,000 seat DaaS initiative. I look forward to see you at Synergy 2014!
Paul Stansel is a Senior Engineering Advisor and architect of Aetna’s 40,000 user global virtual infrastructures across XenApp and XenDesktop platforms. He is a past author of and contributor to multiple Citrix-related books and articles and currently runs http://citrixtips.com/. Paul has been working with Citrix technologies since the WinFrame days and has implemented Citrix at several Fortune 100 companies across the US. You can find him on Twitter @pstansel.
Citrix invited the author of this blog post to present at Citrix Synergy 2014 and to participate in a related contest. The author received an entry into the contest for submitting this Blog.