Watching the developments in desktop service offerings from Cloud providers over the last several years, I have always been interested in their pitch to customers. At first the pitch was all about trying to get them to a monthly price per desktop that was so low it seemed to be cheaper than replacing that old physical PC (also moving from capex to opex). Then, as they progressed, it was about rapid scalability and performance (I mean everyone needs tools to deploy 5000 desktops in 2 hours and 20 minutes right? Everyday occurrence I tell you! Not.). And now, each of the vendors has some take on how their service is “a managed environment”. Take away those management headaches! Their copy reads in such a way that you (as that IT Admin down in the dirt and the bits) will not have to do anything but click and approve new desktops and all will be right in the world… er… cloud.
Of course reality is much harsher for Cloud desktop services, and for the IT admins that get asked about it from their boss.
Most of the ‘cloud desktop guys’ don’t understand the real ‘desktop guys’
The reality is that desktops are not what cloud providers are often selling. What they are selling is what PC manufacturers have sold all along, of course without the physical part of the machine. They are selling a VM with a pretty vanilla load of Windows and maybe a few applications installed (such as Office, Adobe Reader, etc) with the minimum amount of resources needed to run those applications. If organizations just ran vanilla images we (desktop and app management folks) would be out of business. What would there be to manage? Windows updates? – no jokes please.
What I’m saying is that the headache with desktops isn’t just pushing go and getting a vanilla image. You can get that anywhere. The headache with desktops is getting “builds” that actually work for your users, in your organization’s departments, with your apps. And, when a user has a poor experience or can’t accomplish their work, they’re going to complain to the ears on the ground, not those in the cloud.
Desktop admins know the scenario well; you have to get this app (that you have never seen before) to Department A’s desktops by Tuesday, when they asked for it on a Friday. Or, get this update to Application X for Department B by Wednesday, or they wont be in compliance with some goofy federal regulation.
Don’t get me wrong, if you have a call center with 10,000 desktops all running 2 apps, cloud services might look awesome and work well for you, right now. But if you are a typical 1,000 - 5,000 seat environment with 50+ various desktop configurations and 200 (or more) applications, how are YOU supposed to use the cloud?
This is what cloud service providers need to understand. They need to solve the daily problems for the desktop admin. Reduce their workload, reduce their time spent every day, make their job easier. CHANGE their operations for the better, and to do this, they need to make it EASIER for the average desktop admin to do their job. Amazon didn’t get BIG because they sold 1,000,000 copies of the same book to 5 or 10 or 50 companies. They got HUGE selling thousands or millions of different products (one and two at a time), to MILLIONS of individual purchasers. All with different needs and requirements.
The desktop world is very much the same. Oh, a cloud provider may get some marquee customers with 10 or 20 thousand seats. But the hundreds and hundreds of thousands of desktops, sitting in tens of thousands of customers in the mid-market will never sign up to build and maintain 50+ images.
They are looking for something EASIER than what they do today. We have to make their jobs (packaging and updating applications, updating the OS, repairing the desktops) easier on a daily basis. We need to make them go to their boss and say “WE HAVE TO HAVE THIS!” instead of the other way around. And of course, by making it easier to use and faster to complete tasks, you drive down operational costs and time requirements for those teams, giving them time to work things other than operations. This is what makes it easier to jump to the cloud for desktops. (I am not going to talk about data location in this article… that is a whole other issue.)
I don’t care how scalable or how redundant your cloud infrastructure is, do you not think everyone is building that? That is table stakes. I could care less that a vendor can deploy 5,000 desktops in 8 hours and their competitor takes 16 hours. How often am I going to deploy 5,000 desktops in one shot? It’s rare. And if you do happen to need to deploy 5,000 desktops you probably wont do it more than a time or two, at most. Besides, they often ignore all of the other work involved like client deployment; migrations of data, training for users on the new desktops, etc, etc. All of these take time. And mid market enterprises in that 2-5 thousand seat range are smoking along pretty fast if they can migrate 200 or 250 desktops a month.
Building and managing your own “cloud” images is a losing battle
After talking to a few providers they generally have 2 or maybe 3 options for you:
- Take the vanilla desktops they offer with apps they offer
- Lowest cost option, lowest headache for you and they may actually keep your system patched up for you!
- Generally will only work for some organizations (like schools that just need a desktop and MS Office for students)… not much use in many business organizations
- Vanilla image + they can do some application packaging
- Here you can get (hopefully) some of your apps into the cloud, but for a cost
- Not all providers are willing to get into this business because ensuring all the apps will work is almost impossible and they really have no knowledge of your apps, how they work, or your licensing model
- Build your own images and upload them
- Here you build a complete image (with the apps needed) for a group of users and then upload it to them to be cloned, over and over
- You need unique images for all of your groups and then will wind up updating the image by hand for any apps or OS changes and doing this for each of the various desktop configs.
Some of the providers do not even offer option number 2. All you get is their base image or “build your own and upload”. But then again if I was building my own and had to update via uploading new images, why not just go on-prem where I don’t have to constantly rev images and can just update the OS or apps as needed, all with tools I am familiar with. Here is where today’s on-prem (VDI and RDSH) tools kick the crap out of cloud desktops.
This is what lots of these ‘Cloud Guys’ don’t get. What desktop admins want is a simple, always works, way to package a NEW application or desktop change and just push it to their existing desktops. They don’t want to create/update 10 or 20 or 50 images because office was patched or another app needs a minor change. Then, of course, wait (as one provider told me) 4 hours or so for the image upload process to finish and then, once the image is available to the admin, to rebuild the desktops… Then two days later they get hit with another update and they have to rinse and repeat for an OS patch.
A step in the right direction, but we need more detail!
Amazon AWS teams seem to be getting the idea of this. While there are things about AWS I don’t like, their new packaging ability with their Workspaces Application Marketplace (WAM) is a step in the right direction. WAM sounds like just another app store, which really isn’t all that interesting to desktop admins. And at its basic level it IS another app store. But, as Jeff Barr points out in this blog they also have a packaging and deployment tool for admins to deploy business apps to their AWS desktops.
This feature allows the admin to capture a new app for their managed desktops. When initiating the capture WAM will launch a new VM in an EC2 instance, which is probably just booting a preconfigured packaging machine like Unidesk does. The admin then simply logs in to that desktop and installs the app. Their tools capture the install, and from the way it is described, it sounds like a type of light-weight application virtualization. I say it “sounds like” because they use the word “isolated” to describe the app package. I haven’t been able to uncover all the details about what is actually going on under the covers and what that means to their expected application compatibility, but this is a step in the right direction by acknowledging the problem and developing a tool to help on-ramp these apps.
If you work for a cloud desktop service, you have to think like a desktop admin, not just focusing on the IT director at a place that has dedicated app and OS teams. Think like that desktop admin. You know the person: the one dealing with OS patches, and App updates and new requests for apps via help-desk tickets and last minute changes to departmental applications. That admin doesn’t want to deal with broker upgrades and storage failures. They don’t want to worry if their gateway is redundant or if they are having a server failure. They would love if that stuff “just worked”. And you have that to offer to them!
BUT, they MUST worry about the applications and end-user experience. No one “in the cloud” knows his or her apps, desktop configurations, or customers. No one. There are hundreds of thousands of apps out there. And these folks are stuck supporting them. There has to be an ‘on-ramp’ for their apps. A simple way for them to use cloud-based desktops with THEIR applications is what is needed. Simple packaging, distribution and updates/changes is what THEY HAVE TO DO. Hardware, gateways, load balancers, brokers… That is what you can take off their hands. But if they are unable to install their 100, 200, 400 applications in a simple way in your environment… Your environment isn’t much use to them.
On the other hand, if they could do this and it’s easier than what they have today, you will wind up with those admins begging their boss to use cloud desktops, instead of them finding 100 reasons they can’t go to the cloud.