Reading between the lines: When does VDI become DaaS?

Defining what is and isn't DaaS.

We’re in the process of writing our next book about DaaS (we tweet occasionally with the hashtag #DaaSBook about it), and one of the many conversations we’ve had regarding the content brought about the question of defining what is and isn’t DaaS. The simple definition of DaaS is that it’s VDI that you pay someone else to manage. Based on that it seems cut & dry: If it’s in house, it’s VDI, but if it’s from a cloud provider, it’s DaaS. Still, through our interviews, we’ve learned that there could be a rather large gray area where any moniker goes.

First, let’s look at collocated VDI. In most situations I’ve encountered with collocation (we used to run at a few colo facilities), the customer rents the space, some power, and some networking, but is responsible for all the hardware placed there. That hardware is dedicated to a specific company since they’re the ones that own it. So, if a company were to take the VDI away from their own datacenter and place it at a collocation facility, they would still have to design all the storage and networking infrastructure, plus the virtualization and VDI platforms. To me, this is identical to VDI, regardless of where it’s located.

But what if the collocation provider does some of the work. Perhaps they configure the networking and storage, leaving the VDI platform to you. I’m of the opinion that we’re simply running our own VDI on top of managed services, but you can see where the gray area is starting to take shape.

Let’s take that a step further and go to a classic scenario that we’ve observed since the dawn of MetaFrame: Outsourced desktops to what are effectively channel partners. It’s not heavily advertised, but if you look hard enough you can find companies, usually local ones, that will host desktops on their XenApp, RDSH, or even XenDesktop platforms. They’re not at the same scale as what you would expect from a “cloud” provider, but you’ve outsourced all of the platform and infrastructure to someone else to run, leaving you to simply manage Windows. There are questions here about multi-tenancy, SPLA, server vs. desktop OSes, and so on, but if we’re paying someone else to worry about all that maybe we don’t care what’s happening on the back end as long as we get our desktops.

Is that DaaS? Perhaps, and that’s the real discussion here. Where is the line drawn? Is it massive scale and multi-tenancy with lots of automation, or is the simple act of letting someone else worry about the infrastructure enough to qualify?

I’m inclined to believe that you have to have the massive scalability, multi-tenancy, and automation to qualify as DaaS, and that Uncle Bob’s Citrix Farm is better classified as a managed service provider than a DaaS provider, but you could make a case that the backend doesn’t really matter. From an enterprise’s perspective, I call up a provider, agree to pay them $x per desktop, and then I migrate my desktops to that platform. That’s the same as a more “traditional” (if there is such a thing) DaaS experience, so does it matter?

I just don’t know. What do you think?

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

I prefer define DaaS as a consumption model first and enabling technology second. There are plenty of technology & service attributes we can debate, but that follows the consumption quesiton:

How does the end-customer pay for "Desktop as a Service" ?

•         If you are buying a Desktop on a per month/per-year basis.  It’s DaaS.

•         If you’re buying infrastructure (as either CapEx or IaaS) independently and then installing virtual desktop management software, you are either building VDI or are acting as a Service Provider building a DaaS to resell.


Yeah I agree with David.. It's about what it looks like. Whether they actually have any automation on the back end shouldn't matter to the customer. (As long as they can meet their SLAs for IMACs, then what do I care if they have the best VMWaCiscoMC vAutomatPlexr 3000 or just a bunch of interns and stacks of Dell 486DX2s?

So to me, "DaaS" requirements are:

(1) You don't pay for / are not aware of the hardware.

(2) You pay by contract for the service

Hmmm.. Now that I just typed that I realize that some of the big DaaS providers don't fit into that. I know a lot of enterprises want to know what hardware their desktops are going to run on, and in fact some providers even sell desktops by spec, meaning the customer can choose.

Also some customers insist on being able to access the raw storage, the network, or the operations side of things.

Also also some DaaS providers allow customers to bring in their own hardware (typically for security/VPN, WAN optimization, storage replication, or backups. So I guess we can't base the definition on that?

So where's that leave us? Can we say this is all DaaS, it's just that some is internal and some is external and some is hybrid? Or should we say this is all VDI? You have internal VDI and hosted VDI?



Another approach is to negatively define "what's NOT DaaS". I think we'd agree that the goals are

a) don't own the hardware / not a capital investment

b) don't operate the infrastructure

c) administration is "as a service" i.e. self-service

Some of the other items (above) are debatable/fuzzy.

But let's focus on the big-picture goals: that apps, desktops, mobility functions etc. are simpler, on-demand, and by-the-drink.


So the debate seems to set in when we shift from the consumption/license model to the specifics of the operations and management.

I stand by saying a DaaS customer doesn't have to manage below the desktop container. It's SLA driven both for reliability and it's core functional capabilities.


So in this situation, Uncle Bob's Citrix Farm would be DaaS? I'm ok with that. And that's even ok if there's a lot of features that separate UBCF from Desktone or Amazon. It's like saying "this is a car, or this is a truck." There's a lot of room to drill deeper if needed, but that's enough information to go on to at least figure out what you're looking at.

As for whether or not you're placing your equipment on site and managing that, I suppose that's just part of the DaaS management that still has to happen on your end. You're still responsible for connecting the users to the their data wherever they may be. If they were at a branch office, you'd have to do the same thing, so it sort of doesn't figure into the equation.

And, if the customer insists on access to the networking, raw storage, and so on, perhaps they're not good candidates for DaaS?

I like it! Good comments! I intentionally didn't get too wordy/explainy in the article because I was hoping this would happen.


I agree with David, but also it depends upon perspective. To the end user it is DaaS, but to the View/XenDesktop administrator it's probably VDI. The person buying a DaaS book will want to understand that perspective and plan accordingly. The reason I say, "probably" is that some DaaS providers are actually serving up collocated VDI to their customers. In other words they are selling desktops but own no hardware.

DaaS customer: "You know I love you Uncle Bob and think you know more about VDI than anyone, but I am worried that your hardware will crash and leave me stranded."

Uncle Bob: "It's okay. I am using BigIron hosting and they are responsible for the uptime SLAs. I'll just be the guy to make sure you get a desktop with the exact applications you need when you log on. I will be the single throat to choke and you won't have to worry about BigIron."


IMO you should be less focused on where exactly to draw the line, and more focused on what has changed, how it's different from what we had before, and what the implications are (for users, IT and the organizations.) After all, that is what people will buy the book for.


"Cloud" and "as a Service" are interlinked and the discussion on what is and isn't cloud computing has been raging since the buzz really began in 2009 or 2010. Here's a blog I wrote about it back then:

In any case, I'd say that the dimension for cloud (in order of my priority) are:

1. commercial: Consumption based cost where the  consumer/customer doesn't own the hardware and doesn't perform most of the administration tasks

2. technical: Often hosted off-premises with no insights or interest on the side of the customer on HOW the technology is implemented (hence the term "cloud")

3. practical: Often massively and elastically scalable. (See Brian's article on the cost of building VDI or DaaS on premise). Otherwise, the cloud providers would not be able to compete.

Those are my purist definitions and I agree - the lines are a bit blurry.



Great discussion!  I look forward to the release of the book.

I have found it interesting that much of what people want to call DaaS is actually IaaS where the only clear difference is what VM UI is exposed and to whom.  If it is a Server UI exposed for administering a service hosted on that VM then it is generally seen as IaaS, if it is a Server or Desktop UI exposed to end-users for productivity apps then it is usually considered a type of DaaS.  This definitely keeps things fuzzy to say the least.

When we talk about the various approaches inside our product and engineering team focused on these markets we draw the following lines of distinction.  These lines are as much from a technical perspective as they are from cost, it really comes down to “what does an end-customer get for their service dollar, what is the business focus of the provider, and what type of prospect may want what type of service”.

Co-located VDI:

End-customer managed compute, networking and storage for VDI, on end-customer owned or leased hardware, as specified by the end-customer but hosted within an outsourced datacenter.  

Infrastructure is paid for on a term basis.

Software licenses are generally procured as perpetual licenses and are owned and managed by the end-customer.

DIaaS (Desktop Infrastructure as a Service):

Service Provider owned, cloud-scale compute, network and storage infrastructure augmented with Desktop base VM image management and provisioning.  

End-customers manage all other aspects of desktop and application life-cycles within their dedicated compute, network and storage context.  

In most instances these desktop resources are connected back to an end-customer owned datacenter for access to premise managed legacy applications and end-customer owned and managed account authority.

Infrastructure is paid for by the min, hour, month, or negotiated term.

Software licenses are generally (especially for Windows Client OS if offered) procured as perpetual licenses and are owned and managed by the end-customer (BYOL).  Windows Server based VDI solutions may be subscribed to in these scenarios, and in most cases are offered during a technically limited demo/eval phase.

DaaS (Desktop as a Service)

Service Provider owned and managed; Desktop, Application, and Data services as finished goods, leveraging service provider owned and managed cloud-scale compute, network, and storage infrastructure and provisioning.  

End-customers subscribe to these finished goods services and can extend these services with custom applications and SLAs negotiated at an incremental cost to the base subscription prices published by the DaaS provider.  In some instances these desktop resources can connect back to an end-customer owned datacenter for access to customer premise managed legacy applications and an end-customer owned and managed account authority.

Infrastructure costs are included as part of the finished goods service.

All software licenses are managed by the service provider, included in the DaaS subscription, and are based on Microsoft SPLA or complementary third party licensing programs for the management and application layers.  SPLA compliant RDS Session Host and/or Windows Server based VDI solutions may be subscribed to in these scenarios.  Additionally, some DaaS providers include an option for Windows Client OS VDI to be provided on service provider owned and managed, end-customer dedicated hardware.  In this niche scenario the Microsoft licensing for the Windows Client OS is procured by the end-customer through Microsoft VL programs, as in DIaaS the licenses for this group of desktops are owned by the end-customer (BYOL).

Uncle Bob’s Citrix Farm (UBCF)

Uncle Bob’s Citrix Farm is just that.  He’s a great guy, and makes some killer BBQ ribs, but… 


DAAS (and the other horrible buzz words like Cloud and IAAS) are just marketing crud to gloss over the reality of what it is.

DAAS = you want someone else to run your virtual desktop environment for you

Cloud= you want someone else to run your servers/storage for you

IAAS = you want someone to provide you server/storage resources

Not saying that any of these are bad.... just being honest about what DAAS, etc really is.

VDI, on the other hand is a method of providing the desktop... nothing more, nothing less.

It's your desktop.... running on virtual hardware.... doesn't matter where, or who is providing it.


@Dan, @Travis -> Yup. You say tomato, I say tomahto. She says apartment, I say flat. He says provisioning. They say deployment.

There are always exceptions, especially when it comes to "remote access." Is LogMeIn/TeamViewer/PCAnywhere/GoToMyPC considered DaaS or VDI (or perhaps neither)?

All networks (LAN, WAN, MAN) are IaaS.

When it comes to remote desktop compute and access technology, let's take a vote to help those Silly Marketing folks drink their own kool-aid and eat the crud (with acknowledgement to @Travis).


When we host the Daas and they don't !

Its all about custom built DaaS solutions I think, one size fits all does not work with DaaS :