Is DCF the new VDI?
So what exactly do we mean by “Desktop Cloud Fabric?” It’s easy to say it’s the successor to VDI, but we know you are way too savvy to let us get away with not elaborating on that further.
So let’s set the stage a bit. It’s easy to think of “cloud” as this overused buzzword for most types of network-delivered services these days; and quite frankly, it’s nebulous (pun intended). But these services don’t just materialize out of thin air — they have to be hosted on something. And hosted doesn’t necessarily mean it’s something Google or Amazon controls and delivers to your browser — it means the infrastructure that these services originate from.
Cloud infrastructure implies a lot of goodness that we all want. In fact, the National Institute of Standards and Technology (NIST for short) defines “five essential characteristics” for cloud computing:
Essential #1: On-demand self-service
In consumer terms, this means an individual can provision their own resources. In practical business terms for desktops, this means a user logs in, thereby triggering the provisioning they are entitled to. There’s no need to “request” a desktop session, it just shows up. Think of an organization called “Sales.” There’s an Active Directory group called “Sales” that has a number of users within it. When a new user joins the organization, the IT administrator creates their login account and adds it to that group. By the time the user logs in, their desktop is ready to go. If you don’t really think that’s self service, the Desktop Cloud Fabric has a REST API that can be connected to a portal, so the new employee can provision their own desktops. But chances are, organizations don’t just provide self service to add user accounts to Active Directory; so in reality, the login itself triggers the self-service.
Essential #2: Broad network access
This is the real reason we love cloud computing as end users — we can get our services anytime, anywhere. Of course that also means we have to be connected. In infrastructure terms, the challenge is two-fold.
First, you have to make the services available to your users, which in this day and age, are probably spread out all around the world. There’s this nasty thing called the speed of light that gets in the way when moving data over long distances, and this directly impacts user experience when using remote desktops — assuming of course the underlying service providers can keep the network up at all times. When you’ve got a data center in Texas and a population of users in India, this is hardly a given.
The second challenge is equally daunting: protecting information and ensuring compliance. So in addition to providing access to your users, you have to federate it. Naturally this means decentralizing the processing, networking, and possibly even some of the data. This is where the “fabric” comes in — yes, it’s a cloud, but it’s also extending in another dimension, to span multiple data centers or branches and still present a unified management model. Having this capability is essential to “Broad network access.”
Essential #3: Resource Pooling
This is where multi-tenancy comes in. In most large virtual desktop deployments, you have to host multiple organizations and provide delegated administrative controls to them. That is, assuming you are actually deploying and not just getting frustrated with someone else’s technology that doesn’t scale past a few dozen users — but I digress. The last thing you want to do is create multiple deployments to host all of this. That’s right — Desktop Cloud Fabric is also multi-tenant, with tenant types ranging from divisions, departments, or even customer organizations (if you are a managed service provider or MSP). And by the way, this is part of the infrastructure and not a 3rd-party solution that needs to be added.
Essential #4: Rapid Elasticity
So now you’ve plunged head first into deploying your Desktop Cloud Fabric, and suddenly, it’s so popular that you have to keep increasing its capacity on a daily basis. It’s time to get out the sizing sheets, read about the step functions, buy varying quantities of ancillary products, etc., right? Wrong! With Desktop Cloud Fabric, you get horizontal scalability — so literally, it’s a matter of adding more of the same stuff to increase the capacity. If you’re already hosting 150 users per server, and you need to add capacity for 450 more users, you simply buy 3 more servers of the same class. And then it’s off to the complex exercise of tuning, configuring, and replicating, right? Again, wrong! You just turn them on, connect them to the network, and they start receiving load immediately. You can even automate the “connect them to the network” part so all that stuff happens automatically once you flip the switch. Rack, stack, and off you go.
Essential #5: Measured Service
Now that your desktop cloud is running, you want to make sure it’s providing the right experience for your users, and you want to keep track of the actual usage. And of course, you may have to do this across multiple data centers, branches, or even customer organizations. Some of these organizations may want their own reports, both real-time and historical. No problem. Desktop Cloud Fabric keeps track of all this for you, including easy to spot heat maps so you can recognize trouble before your users do. You can measure at the deployment level, server level, session level, and even peek inside the virtual desktops themselves, all the way from a summary view to detailed information. You can also produce customized charts to add to reports, allowing you to easily show off the information to the rest of the world. You can even export all this data in various formats. And of course, you can delegate the reporting in a multi-tenant way, so you don’t have to mine data on behalf of your customers (internal or external).
As the owner of a successful desktop cloud, the last thing you want to do is bury yourself in busy work on behalf of others, and with delegated controls, you don’t have to.
So the question becomes, why shouldn’t your VDI be more like a Desktop Cloud Fabric? After all, who wouldn’t want these capabilities in their deployment? And that’s exactly why we call this the successor to VDI.