A little while back I have published blog posts and videos describing what a Desktop-as-a-Service architecture should look like. I was wrong! Well, let me put this way – there are multiple truths to the matter.

In a previous article I said that DaaS solutions should oblige the following guidelines:

• Build upon the foundation of private/public cloud
• Secure Multi-Tenancy
• Elastic Resources
• Automated Provisioning
• Identity Management, Federation and Role Management
• Self-Service Portal
• Reporting and Metering

All that time I was focusing on DaaS aspects that relate to large service providers’ implementations. There is nothing wrong with that, especially given that at the end of the day service providers are the big players in this space. Microsoft is joining the game with the unofficial project ‘Mohoro’ (link), and even Dell is providing virtual desktops.

The reality is that any organizations, small or large, could have a successful DaaS implementation simply creating an self-service portal where users and consumers can unilaterally provision virtual desktops, as needed automatically without requiring human interaction with each service provider.

Self-Service Portals should be an easy-to-use web interface that abstracts infrastructure information from users. Hardware information such as datastores, resource pools and desktop images should not be something that users should be required to have knowledge about. A user should be able to simply request a Windows desktop with Office 2010, 2 vCPUs and 4GB RAM.

So where does that lead us with all remaining components?

They are important, but not essential for DaaS deployments.

Multi-tenancy is the property or architecture feature where separate software instances or hardware systems are set up for different client organizations. Multi-tenancy may cover multiple areas, including not only CPU and memory resources, but also networking and storage.

Multi-Tenancy may not be required if you are deploying DaaS to a single entity, organization or enterprise. Multi-Tenancy starts to become more critical when more organizations share the same hardware infrastructure or multiple authentications boundaries start to interpolate.

Elastic Resources is the component that allows automated expansion and contraction of infrastructure resources. Whilst most cloud-based solutions will provide some form of elasticity, the component is also not a critical piece for many forms of DaaS. As an example, the administrator could ensure that there are enough resources available for the foreseeable forecast.

Automated provision is the component that ensures that desktops requested via the self-service portal are properly created. Most VDI solutions on the market have automated provisioning built-in and also provide some form of API’s that can be used to request creation of new desktops. However, it’s also possible to have the administrator to ensure there are enough desktops available for the foreseeable forecast, eliminating the need for automated provisioning.

Identity Management, Federation and Role Management. Having the ability to explicitly access internal, external and corporate resources in a secure and authenticated manner is essential. However, that doesn’t mean that for a DaaS solution you are obliged to support multiple Active Directories or authentication boundaries. Your DaaS solution could simply be connected to a single Active Directory source, whilst admin accounts could have been manually setup.

The ability to meter and report usage based on different and relevant metrics such as CPU and Storage consumption could be important for many DaaS deployments, but not all. Some organizations may want to show back utilization back to the business in order to justify investments, while other may want to charge-back different business units.

Ultimately, what I am trying to say here is that you don’t need to be a huge organization or a service provider to create your own Desktop-as-a-Service solution.Over the next few blog posts I plan to exemplify how you can build your own DaaS solution with VMware Horizon View and few other components from the VMware portfolio and/or Open Source.

If you want to go ahead and explore the subject I would recommend you to look at project mycloudportal. My Cloud portal is an open source self service layer for the cloud, but it can easily be used for your DaaS solution. The project can be found here. Another option is to use VMware vCloud Automation Center as your frontend (here).

This article was first published by Andre Leibovici (@andreleibovici) at myvirtualcloud.net.