I recently wrote about five VDI anti-patterns on ViewYonder.com - which is an above-the-water, tip-of-the-iceberg look at desktop-as-a-service operations.

I'm interested, and willing to swap for beer tokens, in hearing stories from consumers and providers of virtual desktops with a view to building DaaS patterns (and anti-patterns) that, despite or in spite of the technology components, everyone can recognize a DaaS when they see one.

This will enable apples-to-apples comparisons of VDI solutions across business verticals, which helps consumers understand where they are / want to be. It also helps providers so they can explain their USP in a recognizable context, and also deliver against a standard or just a part of it.

So when it comes to VDI management, for me and enterprise customers I know it's about end-to-end management, like capacity from desktop pipeline on the front end to infrastructure on the back-end. It's also about slapping service level management on top of it so you can see the capacity, availability, integrity and confidentiality options through a service catalogue.

I'll shut up now, you'l be glad to hear :-) But check out the image above for how complex a DaaS can be to manage... :-)

I see you reference DaaS, rather than enterprise VDI. This may be just a difference in terminology, or maybe even a "religious" issue (!), but I think there is a substantial difference between these two. I do see how VDI can be delivered "as a service", and that all the various contingencies of IT need to be involved in assuring that service delivery - but I personally think that what separates DaaS from enterprise hosted VDI is very much the same as the difference between an enterprise hosting a CRM and using Salesforce.com (SaaS).

I think of DaaS as being a service, hosted "in the cloud" by some third party provider (maybe with on-site services, but hosted management none the less). This means that the service provide has to solve a wide range of other issues, including multi-tenant service delivery, secure data storage and communications, tenant specific authentication (e.g. gateway to AD/LDAP pre-authentication), and the somewhat mundane but surprisingly complex metrics of operations that integrate back into a billing engine.

If DaaS doesn't mean this - but instead means that overall management, delivery and measurement of desktops being delivered within a corporation - then what do we call a outsourced hosted multi-tenant desktop delivery service? Considering SaaS is well known, DaaS makes sense to me!

I know this isn't what you were looking for, but I thought I'd add this to the soup anyway!

Hey Chris, I guess I don't differentiate between Public or Private DaaS. If it's a service, no matter who delivers it, then it's a service.

The DaaS Provider worries about how to satisfy market demand - meaning product, price, etc, and providing interfaces to the customer through Service Catalogues and Service Level Agreements.

The DaaS Consumer has requirements (not specifications) that are satisfied by a number of products available in DaaS:

1. Get a real, fat desktop delivered to your desk.

2. Get a thin client + a real desktop (blade) in the DC

3. Get a thin client + a virtual desktop (on ESX) in the DC

I guess it's all terminology so we won't pull each others hair... but VDI is just one desktop delivery solution (so my customers keep telling me!).

Cheers

Steve

hmmm, interesting perspective- requirements not specifications. I like it! I guess I was thinking more along the lines of DaaS as an external entity offering the service and mainly b/c of how I view SaaS. Just goes to show you that nothing is cookie cutter in this space yet, I guess when someone says they are interested in DaaS, the best question to ask back is.... "tell me what that means to you" Rock on...

absolutely, MIchelle! Someone said (on twitter) the other day that if IT asks you for your requirements, then #itfail : I couldn't agree less.

The enlightened customers I work with want to spend more time listening and helping their customers be successful, and it's impossible to know all the solutions before their customers come to them.

This different thinking can be illustrated:

1) If IT knows all the answers before customers approach them, then the service catalogue offers specifications and solutions to choose from.

2) If IT doesn't know all the answers before customers approach them, the the service catalogue asks their requirements and matches those to either an existing solution or rejects or offers a custom exception path.

I like (2) and so do my good customers. (1) is more common and preached by old thinking.

My 2p!

I think your focus there is on an organisation that only has its own applications and services hosted and managed internally; where the user workspace is considered 'the desktop' when in fact their workspace is far much more.

I've worked for a number of organisations where there's a major application that's not hosted internally. A service management team works with the supplier - but ultimately there's very little internal teams can achieve - yet the performance of that application is key requirement for users. Although its part of the user's workspace - its not part of the desktop.

With any growth of DaaS I think there needs to be more awareness of an 'application' layer operating independently of the desktop - delivering functionality to the user's workspace; but not part of the desktop - and quite sourced and delivered outside of the organisation.

I agree that the users' requirements should drive a project. User's requirements will focus on what they do (their apps) will focus on what they work with (their Data). The delivery and management of those are key - far more so than the delivery and management of the desktop OS.

I think an apples-for-apples comparison can only happen when you've the same application type and data store - and that rarely happens.

For instance - lets take a document management system. Not only do you need to store the document, but have an app to edit the doc consistently, allow the doc to be transferable, searchable, possibly interact with embedded macros.

How a new organisation may view their requirements here compared to say an established organisation are going to be very different - and that may well be in a vertical market.

And that's before we mention security - which is the classic "someone else's problem"

I've seen a number of DaaS solutions that offer business standard apps and desktop "availability"; essentially treating the "D" as you would do a single entity.

But a user's workspace - a workspace encompasses so much more . Without looking at "application", and indeed a 'user' layer you'd fail to deliver anything near what needs to be part of a DaaS solution that can offer businesses agility and reduced costs.

Interesting, Andrew -

I think you provide a glimpse at the complexity of linking users to applications, and talk to the desktop as one of the portals to achieve that... and that a new company might not be held back by the legacy...

But don't application providers force new users into the same legacy approach (their apps are only supported on desktop)?

Assuming that there is (a) desktop as aportal to apps, and (b) A.N.Other method, then DaaS = route a and route a is huge?

I'd agree a lot of application vendors create applications that have a number of dependences. Its not just 'legacy' apps that are dependent there - even "web" based apps might need a particular version of IE, or not work with Chrome :?

Some apps (especially if they interact with some h/w) are going to be fixed to a device/OS. Some apps don't work virtually.

Because of this I don't think you can think of DaaS in isolation without thinking how users expect their apps to work.

Perhaps you consider DaaS as your current desktop - virtualised "somewhere" and managed for you. But then the end game is that you're tied in to that supplier; you've got to migrate to that suppliers environment. All costly - and not dynamic: although it does map onto the diagram you'd have above.

Perhaps what you'd like is to have a workspace environment managed and then apps (potentially from many vendors) delivered into that environment. That's very complicated - but that's where DaaS - and even an in-house VDI deployment needs to be thinking about as the application and user virtualisation as that's allows you to move away from the desktop being a fixed 'thing' to a more dynamic, yet more manageable service.