The other week, while giving a demonstration of our VDI management platform, I tossed out the word “orchestration”. It’s a term you often hear from organizations that are moving resources into the cloud. Invoking the orchestration card, however, brought on the question of how, exactly, our platform was different from all of the other cloud orchestration tools on the market.
Good question, I thought. And, not one that applies specifically to our platform.
The answer requires looking at what orchestration means in the context of VDI, and in particular about how VDI weaves into your organization.
What is cloud orchestration?
First, what is cloud orchestration? In fancy terms, cloud orchestration refers to the arrangement and coordination of automated tasks resulting in a consolidated process or workflow (1). Said with less flare, Cloud orchestration is the end-to-end automation of the deployment of services in a cloud environment (2).
There are many, many cloud orchestration tools in the field, for example, Chef, Puppet, Juju, OpenStack Heat, AWS CloudFormation, and the list goes on. Generally, using an orchestration tool, you define reusable templates that build the components you need to deploy a particular, for example, application.
In the case of VDI, you can use traditional cloud orchestration tools to do the day one task of building your environment. You define networks and subnets, configure master desktops and deploy applications, create images from master desktops, build storage accounts, and more.
But then, you move onto day two.
How does orchestration fit into VDI?
Day two orchestration needs to focus on maximizing the business value of everything you built in day one. It needs to make users more productive while reducing operating expenses and risk (3). In the case of VDI, the members of the orchestra are your end users, and their instrument must ensure that they always connect to the best desktop for their job.
But, if a VDI orchestration tool is responsible for connecting users to their desktop, that’s not its only job. The tool also needs to model and enforce business processes and goals, by giving IT control over the user’s desktop session, as well as over the entire VDI environment.
So, how do you orchestrate VDI?
To efficiently orchestrate VDI, make sure you define all of the different user workflows you need to satisfy. Consider where users log in from, what type of client device they are using, how much compute power they require to get their job done, and how long they are allowed to consume that compute. Then, look for a tool that allows you to model those workflows.
Do you plan to provide pools of desktops, enabling users to share acces to expensive applications? Do users need to collaborate a particular desktop session, so employees around the globe can work on complex assignments? Would you save money if your environment was elastic, so new compute was provisioned and terminated to meet demand?
A comprehensive orchestration tool for VDI allows you to define templates that model these kinds of workflows, and more. You want a tool that automatically directs user logins to the right place, and automatically manages desktop sessions in a manner that maximizes your business goals. That automation frees IT to perform other tasks.
Standard day-one orchestration tools don’t particularly excel at modeling VDI workflows. The tool that does is a VDI connection broker.
And, that brings me back to the comment I made during my demonstration.
A connection broker is, in a sense, a day-two orchestration tool for VDI. It’s not a cloud orchestration tool in the sense of being a full cloud management platform, but if you plan to move VDI workloads into the cloud, the connection broker is a key piece of technology for maximizing the potential of that environment.
So, next time someone asks me that question, now I have an answer!