An orchestrator refers to a software system programmed with workflow rules and business logic that facilitates automated actions and integrated connectors to external software systems. Many IT organizations create scripts to automate manual tasks; however, these are now considered a legacy technique. Scripts are also difficult to maintain and reuse, and their sequential processing limits their flexibility.
An orchestration system goes well beyond scripting with parallel tasking, branching workflows, situational-awareness logic, and the ability to back out from or resume workflows that fail or sense an error.
You can integrate Scripts and other automated software installation packaging tools into an orchestration workflow; however, the orchestration should always be the primary logic engine at the core of all cloud provisioning and automation workflows.
Orchestration: Use-Case Scenario and Walk-Through
- The customer logs on to the cloud service catalog portal and orders one virtual machine (VM) with Linux as the OS, 4 processors, and 16 GB of memory.
- The customer processes his order through a shopping cart check- out process and submits it.
- The orchestrator detects this new customer order and sends an email to the designated approver(s) within that customer’s organization.
- The person who approves orders receives the email and clicks the URL within it to log on to the cloud management portal. A list of pending orders awaiting approval appears, and he approves the order.
- The orchestrator detects that the order is now approved and begins the automated provisioning process. The orchestrator connects to the VMware server farm and instructs VMware to create one VM based on the Linux VM template.
- VMware creates the VM as instructed. The orchestrator then changes the configuration of the VM so that it has four processors and 16 GB of memory. The orchestrator then instructs the VMware software to boot the VM for the first time.
- The orchestrator logs on to the VM, knowing to use Linux commands, to confirm that the system is functioning correctly. The orchestrator completes any additional steps the cloud provider has configured, such as installing additional software updates or patches.
- The orchestrator connects to the cloud provider’s change control system and enters a record in the database indicating that a new server—VM in this case—has been brought onto the network. The orchestrator populates the IP address and other configuration information into the change control system so that the cloud provider’s support staff now knows that this new server exists.
- The orchestrator is aware that the VM has been successfully created, so it sends an email to the customer indicating that the VM service is available. This email notification contains the new VM server name, IP address, and logon information.
- The orchestrator sends out error notices (or uses an API call to an existing service ticketing system) to the cloud provider’s support staff if any step in this process failed to complete or if any of the downstream software systems generated an error. You can configure the orchestration workflow logic to pause if an error or failure is detected (to give cloud support personnel time to resolve the problem rather than generate an error to the customer). Upon fixing the error, the cloud support personnel can continue the work-flow, and in some cases the orchestration system can automatically detect the change in status and resume the work- flow automatically.
In the preceding example, VMware was the hypervisor technology. There are numerous hypervisor technologies in the industry that would perform similarly; however, a key point to highlight is that the hypervisor software itself is not the same as the cloud management platform. In this example, hypervisors perform only the creation and management of VMs.
Note that some hypervisor software platforms can perform some higher-level cloud management functions but are usually not as complete and all-encompassing as a full cloud management plat- form. It is the cloud management system that performs everything from taking the customer’s order from a service catalog to the approval process; to triggering the hypervisor to provision services; updating the network management systems with the new VM configuration and status; starting utilization and invoice tracking, and finally, sending email to the end user and cloud support staff of success.
Key Take-Away
The earliest cloud systems often relied solely on the hypervisor software’s portal or configuration tools. These hypervisor configuration portals are good for technical personnel to manage basic VM services for a single tenant organization. Multitenant clouds with more advanced PaaS and Software as a Service SaaS applications utilize full cloud management platforms that automate and orchestrate the entire infrastructure and customer portals—the hypervisor software is now just an underlying component of the cloud management system.
The below figure shows a diagram published by NIST that maps service orchestration to the NIST Cloud Reference Model.
NIST model for cloud service orchestration (Source: NIST, Special Publication 5-500-291 version 2, July 2013)
