A short history of Orchestrator

Orchestrator started its life as Virtual Service Orchestrator (VS-O) with a small company named Dunes in Lausanne, Switzerland. In 2007, VMware bought Dunes, renaming the product as VMware Orchestrator (VMO), and then introduced Orchestrator into vSphere 4.0 as vCenter Orchestrator (vCO). Orchestrator's first stage debut was with VMware Lifecycle Manager, which used Orchestrator to automate the virtual infrastructure life cycle.

Orchestrator itself never really received the spotlight until the recent launch of VMware vCloud Automation Center (vCAC). In the beginning, vCAC used Orchestrator only as an extension, but with version 6.1, it became the central tool for automation.

In October 2014, VMware renamed vCenter Orchestrator (vCO) to vRealize Orchestrator (vRO) to align with their new strategies. vRO is not a new product; it is just the new name of vCO. VMware also renamed vCAC with version 6.2 to vRealize Automation.

In vSphere 4.x and 5.x, Orchestrator was automatically installed when one installed vCenter. Orchestrator began its life as a Windows install, which was finally phased out with the introduction of vSphere 6. With the start of vSphere 5, a Linux-based Orchestrator appliance was introduced, which now remains the only Orchestrator installation that is officially available.

Since the introduction of vRealize Automation, Orchestrator has become the focus of a lot of development and attention from VMware and others. More vendors have released plug-ins for Orchestrator and many have been discovering Orchestrator as an innovative solution for their automation needs.

Features of Orchestrator

Most vSphere administrators don't know about Orchestrator, or underestimate its possibilities.

In essence, Orchestrator is a visual scripting tool using JavaScript. The programs/scripts that one creates with Orchestrator are called workflows. Each workflow consists of little building blocks called workflow elements. A workflow element can be a workflow, an action (a JavaScript script), or one of many other predefined commands. We will work with workflows in Chapter 4, Working with Workflows, and start creating our own workflows from Chapter 5, Combining and Modifying Workflows, onwards. Orchestrator comes with a large library of precreated workflows that cover a lot of the typical administrator work, such as creating VMs or connecting CD-ROMs.

A user can interact with Orchestrator either using the Orchestrator Client, a Java executable, via the vCenter vSphere Web Client or through websites that use the Orchestrator API. Orchestrator uses a full REST API (the SOAP API was removed in 6.x) so tools such as vRealize Automation (vRA) can easily communicate with Orchestrator.

Orchestrator uses a plug-in architecture to expand its base usability, enabling it to not only interact with various VMware products but also integrate with a range of other products. There are plug-ins to interact with hardware from vendors such as HP, Cisco, EMC, and NetApp as well as with other automation solutions such as Puppet and Microsoft SCOM or Microsoft SCVMM. We will discuss plug-ins a bit further down the track.

The following figure shows how one can interact with Orchestrator and how Orchestrator interacts with other solutions:

By executing Orchestrator workflows, one can interact with any Orchestrator technology integrated into Orchestrator. As this still sounds pretty complex, here are some examples:

VMware has been releasing Orchestrator plug-ins for most of its products. This allows you to create workflows that tie all the VMware products together making it possible to easily create interactions between VMware products using a single tool.

The following figure shows all currently existing VMware plug-ins that Orchestrator can use. The green dotted line also shows which VMware products can start Orchestrator workflows.

An example of plug-in interaction could be to create a VM in vSphere and configure it with a dedicated network using NSX, and then configure this VM automatically for SRM. Or another way around would be to use an SRM recovery step to execute an Orchestrator workflow via the API to launch some network configurations in NSX.

So what it comes down to is that Orchestrator is a central tool from which one can control, trigger, and drive separate products in your environment.

More about plug-ins

The real strength of Orchestrator lies in its ability to use plug-ins. Plug-ins can be written by anyone, as VMware publishes a guide on how to write them along with an SDK to help you get started. Plug-ins are mostly written by vendors to make it possible for Orchestrator to access their product. An unofficial full list of all existing plug-ins can be found at http://www.vcoteam.info/links/plug-ins.html.

Additional to this, there is the official plug-in site, the VMware solution exchange, where you can find more plug-ins that are vendor-specific or may require licensing:

https://solutionexchange.vmware.com/store/category_groups/cloud-management

Examples of vendors that have plug-ins are BMC, Chef, CISCO, Docker, EMC, F5, Hitachi, HP, IBM, Infoblox, NetApp, Puppet, and Riverbed.

If there is no plug-in for a program you use, you could always use SOAP, REST, SSH, Mail, or PowerShell to access this program and integrate it into Orchestrator. Another possibility is to use Dynamic Types. Dynamic Types help you construct types and Orchestrator inventory entries enabling you to build XaaS (Anything as a Service). Have a look at Christophe Decanini's posts and examples:

http://www.vcoteam.info/articles/learn-vco/281-enabling-vcloud-automation-center-xaas-with-vco-dynamic-types.html

Orchestrator itself comes with quite a lot of plugins preinstalled. The following screenshot shows all the plug-ins that vRealize Orchestrator 6.0.2 comes with:

In this book, we will work with the vCenter plug-in. All other plug-ins are discussed in detail and with example workflows in the VMware vRealize Orchestrator Cookbook.