I may have just ruined Edwin Starr for so many people. Sorry about that. Let’s talk about DaaS, aka Desktop as a Service.
DaaS is one of the emerging as-a-service offerings being provided by pretty much every cloud provider out there, in one form or another.
The goal here is not to rehash the benefits of DaaS or compare DaaS to VDI. That’s been covered by VMware’s “Top 5 Reasons to Deploy Desktops as a Service,” William Freedman’s article “VDI vs. DaaS: What’s the Right Choice for Your Business?,” and Robert Springer’s “Dueling Desktop Showdown: DaaS Versus VDI.”
Instead I want to look at the common design challenges that face anyone building a DaaS offering. This came about after reading a post about DaaS storage challenges, which can be found on this Storage Swiss blog post written by George Crump. I don’t entirely disagree with him, but here are the challenges as I see them:
- Virtual desktops have high and somewhat unpredictable I/O profiles. This often means desktop environments wind up on dedicated infrastructure.
- Multi-tenancy is hard because of the I/O issue. To provide multiple tenants secure environments for their DaaS deployment, cloud and hosting providers have to ensure there is no data corruption or potential for cross-contamination.
- DaaS customers are a seeming juxtaposition of requirements, wanting to outsource compute/storage/networking and deployment of the virtual desktop environment while also wanting to be able to customize, and in some cases manage, the desktops as well.
- DaaS is more than just virtual desktops. User Environment Management (UEM) and User Application Access are also considerations.
- SLAs/SLOs. There is a saying I came across working with the Air Force: “If the minimum wasn’t acceptable, it wouldn’t be called the minimum.” This pretty much sums up the concept behind SLAs (service-level agreements) and SLOs (service-level objectives). The thing is, with bursty performance needs, how can service providers meet these needs?
Now for the big reveal on how we can provide answers to all of these problems. Let’s take them in order:
Dedicated infrastructure no more
Because SolidFire is able to set Quality of Service (QoS) guarantees at the volume level, we enable DaaS providers the ability to leverage the same storage platform for virtually any workload. This means service providers can harness global efficiencies of dedupe and compression across multiple tenant environments while restrictively isolating each tenant’s data and running desktops next to any of the other workloads they offer to host.
SolidFire secures tenant data and isolates that data to ensure no cross-contamination. This is accomplished by leveraging volume access groups (VAG). A VAG manages a group of volumes and their discovery by the compute side, and an initiator (iSCSI or Fibre Channel) is tied to a VAG. This means multiple initiators would be needed in a shared services model. Not impossible but maybe too cumbersome.
Therefore CHAP (Challenge-Handshake Authentication Protocol) can also be used at a per-volume level to restrict access to the data path. SolidFire further abstracts tenant data by hashing data blocks via ZooKeeper before they are written to disk.
With all of that, the attack vectors are restricted to the servers or desktops themselves or to the infrastructure administration layer, both of which present different challenges — but the storage is secure.
From a storage perspective, SolidFire doesn’t do a lot for the user, as storage is better in the background. It’s the flexibility of the platform that shines here.
If you’re running a DaaS environment, the last thing you want is to manage each piece of the offering independently, thanks to SolidFire API exposure tasks that are easily automated, allowing DaaS providers to leverage their automation tools of choice and get to OPEX savings faster than any other storage on the market.
More than just desktops
Managing mixed workloads is where SolidFire really shines. Imagine running user applications and environment management right alongside the desktops. Thanks to SolidFire’s minimum IOPs QoS setting, we can ensure the noisy desktop neighbor doesn’t impact applications and that the UEM solution gets served quickly.
Disaster recovery and continuity of operations are also pretty standard concerns. Here we have the ability to provide synchronous and asynchronous replication from site to site (integrations with failover solutions like VMware SRM are also available). This means service providers have the ability to put DaaS in a shared services infrastructure environment and see the greatest financial and operational efficiencies.
But just like any good infomercial: Wait, theeere’s more! SolidFire’s shared-nothing architecture allows for easier global data center scale planning, with proactive monitoring and the ability to remove excess nodes and ship them via your preferred material handlers to other data centers where they are needed most. We are changing the way you procure and manage your storage for not just DaaS but for any workload. This flexibility provides the needed business agility to go through the 3 P’s of VDI (POC, pilot, production), to rapidly expand for new acquisitions, or to be the platform for your DevOps initiatives.
Finally, SLAs and SLOs: the dregs of any DaaS operations staff and the nightmare of most data center managers. SolidFire has the ability to provide the minimum IOPs requirement for any workload in a cluster at the per-volume level. This minimum provides a guaranteed level of service and can be tuned over time to ensure it meets the SLO requirements.
DaaS is a different beast but one that SolidFire is able to help tame and turn into a solution that makes sense for customers and partners alike. For more information, visit our DaaS solutions page, and while you’re there, request a demo to see SolidFire in action.