Jack and I are giving a presentation at a BrianMadden.com After Hours event in Washington, DC this week, and while I was mapping out my portion of the presentation, I realized that I wouldn’t be able to hit all the topics I want to talk about in a short period of time. One of those topics is the state of the DaaS industry, which I really want to talk about. So, instead of carving out a block of time that will inevitably be too short, I decided to write about it here.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
(If you attended our show and are circling back to read this, it was really great to hang out with you on Thursday night. Those conversations we had were really something, and I’ll never forget them once we have them.)
In 2016 Brian and I both gave presentations entitled, “State of the DaaS Industry in 2016.” Brian gave his at Citrix Synergy, and I gave mine at BriForum. After my session, people came up to me and said “I thought this was going to be the same as Brian’s, but you were way more positive.” This really sums up our relationship. One zigs, the other zags, and when the two lines meet funny, often productive, things happen. In this case, it comes down to the barriers for DaaS adoption, and while there are currently more than you can count, they are slowly being chipped away.
That said, many things this year have happened that are encouraging to me. More companies are warming up to the cloud in general, and as more services and systems make their way out of our datacenter, our comfort level and ability to move our desktops out increases. Microsoft has made some significant announcements and licensing changes. Plus, we have new deployment scenarios that weren’t around when we wrote our 2014 book called Desktops as a Service (which is due for an update), like on-prem DaaS using local cloud nodes. There are also many new providers, and some of them truly believe they are deliver magic desktops. (This is both good and bad.)
This article is rather long, so we’re breaking it into two parts over two days. This is Part 1. Tomorrow we’ll have Part 2.
Establishing Ground Rules
Before we get too deep, let’s frame this conversation. First, when we talk about DaaS, we talk about remote desktops that you pay someone else to host. They could be VDI or RDSH–it doesn’t matter. It is NOT, however, managed services. That’s different, and entails managing Windows in addition to your VDI infrastructure. You can get that along with DaaS, but you’re not going to get that for a dollar a day.
So when we talk about DaaS, we’re just talking about desktops. You still have to manage and secure them. You still have to deploy applications to them. And you still have the manage the end users’ experience, right down to the client on their desk. Each of these things presents a new challenge, or at least a new spin on an existing challenge.
Ok, so the fact that DaaS is just a desktop is sinking in. Now you have to figure out how to navigate some new things that were off your radar before. User and application data location all of a sudden matter quite a bit more (do we leave it on-prem or put it in the cloud? Which provider?), as do SLAs and your internet connection. Plus, you have to find a provider you trust and decide where to put your other resources like authentication and systems management. Let’s look a tad deeper.
When you move desktops to the cloud, you still have to have endpoints that can access the desktop running remotely. You have lots of options, like installing thin clients (many providers have recommendations on what to buy). Of course replacing PCs with thin clients can get costly, so an alternative would be to repurpose those PCs as thin clients. You can either leave Windows on them and lock them down (though in that case you’re still managing Windows so why bother) or replace the OS with one of the many PC-to-thin-client conversion tools out there. Stratodesk, Igel, Dell WYSE, and most others have one. These allow you to continue using that old hardware while locking it down and managing it with the same console you’d use to manage your other thin clients.
There are other options, too, but they get a little more far-fetched. You could implement a company-wide BYOD program and encourage users to use their own systems. You could buy everyone Chromebooks or iPads or something, too. Those are less common, for sure, but it’s important to understand that moving to DaaS doesn’t help you with endpoint management. That responsibility is yours as much as it ever was.
Internet and the User Experience
When your desktops are local and the internet has a problem, what happens? Facebook notices a drop in connections from your IP address, but basically users’ productivity continues on because all the systems are local. Latency is no big deal, either, because who cares or even notices is a search query is returned 100ms slower?
Now move your desktops outside your walls and access them through the internet. In addition to the increased bandwidth, you’re way more susceptible to the effects of a crappy internet connection. A small amount of latency affects every single user, and every single interaction each of those users has with their applications and data. Even though you’re paying someone else to manage the virtualization infrastructure of your desktops, the users still call you when their experience suffers.
Internet becomes more than mission critical when you use DaaS, and don’t forget you have your connection and your provider’s connection that can screw something up. You’ve got to trust your provider. Also, like it or not you’re still the defender of the User Experience. It’s the plight of the desktop virtualization admin. (Sniff) We love those damned users.
Wait, did you think we were done with how much you care about the internet? Sure, we care about it from a quality standpoint, but you’re also likely to need more bandwidth depending on how you locate your resources. For example, when your desktops are in the cloud, what will your users authenticate to? Will you put domain controllers at the DaaS provider, or will the users authenticate across the VPN back to your on-prem systems?
What about file shares? Will you place file servers at the provider, or will that data also be shipped across the VPN? Or perhaps you’re going to move all of your file shares to a cloud service, in which case you should probably start/complete that project before you get moving with DaaS. No need to make it harder on yourself.
The same goes for application data, which is the one that many people often forget about. One of the reasons we went to datacenter-hosted desktops in the first place (way back in the 1900’s) was to locate our desktops closer to the application data that resided in the datacenter. That’s still a benefit today, assuming you still have applications that run on-prem. But what do you do when you move the desktops out of the datacenter, not just out to the LAN but across the country? Does all that application data traverse the VPN, too?
You’re gonna need a fat pipe.
Or maybe not. Maybe you’re at the forefront of cloud adoption. If you’ve moved all your file sharing to a EFSS platform, all of your datacenter-hosted applications to the cloud, and are using an IDaaS (Identity as a Service) to tie all of it together, go to the head of the class! But if you’re like most companies, you’re probably going to struggle with some or all of these things.
In addition to all of the technical challenges, there are also mental ones that still plague some companies. As time goes by and people warm up to the cloud, these have become less significant, but they are in many cases very real.
Companies worry about the other customers that DaaS providers support, and whether or not they’re doing something illegal (the provider or the customer) that could result in a shutdown. They worry about the provider going out of business, too. It’s a valid concern, and I would caution everyone thinking about DaaS to create an exit strategy for both a graceful exit and an emergency exit.
Additionally, companies tend to worry that the providers aren’t as committed to their desktops as a company’s own employees would be. We have an emotional attachment to them, mainly because our jobs depend on them. How committed is the provider to those desktops?
(The reality here is that the provider is probably more committed to the desktops than you are since they’re not being pulled in as many different directions. All they do is deliver desktops, and if they can’t deliver desktops, they don’t have a company.)
There are other, smaller challenges that may have to be overcome. Data sovereignty is one such thing. Are you allowed to store company information outside your datacenter walls? Outside your state? Outside your country? Most restrictions in these situations are manageable, but it’s the kind of thing you want to figure out now instead of halfway through the deployment.
Provider flexibility is another potential challenge. Don’t think you throw your big company weight around with a DaaS provider by demanding anything more than their cookie-cutter desktops. DaaS providers operate on thin margins, and the only reason they can do what they do is by making things as repeatable as possible. It’s not as profitable for them to bow to your demands to have 2.5GB of memory for every desktop when it distracts them managing all their other customers’ 2GB desktops.
You also have to worry about monitoring, because like it or not you’re still going to have to hold the provider accountable. You can just say “You guys are slow,” without expecting to get the finger pointed back at you. Invest in monitoring platforms, and while you’re at it, make sure you understand your SLA.
That seems like a suitably downtrodden note to push pause on, but I promise part 2 will be more upbeat. Yeah, there are challenges, but tomorrow we’ll look at the benefits and use cases that are appearing, plus ways people are dealing with some of these challenges. After all, my outlook is the more positive one, right?