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.

 

Use-Case Scenario: Orchestration

1. The customer (your firm or your Cloud Admin), logs on to the cloud service catalogue (eg ServiceNow) portal and orders one virtual machine (VM) with Linux as the OS, 4 processors, and 16 GB of memory.
2. The customer processes his order through a shopping cart check- out process and submits it.
3. The orchestrator detects this new customer order and sends an email to the designated approver(s) within that customer’s organization.
4. 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.
5. The orchestrator detects that the order is now approved and begins the automated provisioning process. The orchestrator connects to the VMware server (or another hypervisor) farm and instructs VMware or the underlying Hypervisor, to create one VM based on the Linux VM template.
6. 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.
7. The orchestrator logs on to the VM, knowing to use Linux com- mands, 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.
8. 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.
9. 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.
10. 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. 

 

A key point from the above 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 platform. It is the cloud management system that performs everything from taking the customer’s order from a service catalogue 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 figure below 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)

 

There are three common methods for provisioning resources in a cloud infrastructure. Clearly, automatic is the preferred method, but there are scenarios in which you would use the other methods, as well.

 

1-Manual, using cloud provider’s web portal

Benefits:

• Simple and easy for customer to understand and self- configure
• Immediate initiation of provisioning activity and visual confirmation

 

Disadvantages:

• Less efficient use of labour
• Susceptible to configuration mistakes; human error
• Potential for inconsistent configurations, adherence to standards
• Cloud provider’s management and billing systems might not be aware of manually configured services or changes to subscriptions

 

2- Programmatic, using API calls from scripts

Benefits:

• Easily integrates into existing software installation tools and scripts
• Often preferred method for software developers, especially for non-production
• Low cost to implement

 

Disadvantages:

• Concerns and conflicts using hypervisor APIs versus provider’s cloud management platform APIs
• Sequential scripts are not as dynamic, upgradeable, and flexible as full automation and orchestration
• Susceptible to configuration mistakes at a faster scripted pace
• All provisioning activities must be synchronized with the cloud provider’s management platform and billing

 

3- Automatic, using cloud management platform orchestration

Benefits:

• Fastest provisioning with least amount of labour/support required
• Real-time provisioning status awareness, billing, and operational readiness of new cloud services
• Consistent configurations resulting in better quality, improve security and compliance to standards/procedures

 

Disadvantages:

• Higher effort to implement and configure full orchestration
• Use caution if automation is configured to allow unlimited elasticity
• Potentially steep learning curve for legacy IT staff to implement/use new orchestration/automation tools

 

RESOURCE ALLOCATION

One key feature of orchestration and provisioning is resource allocation. In this process, the cloud system takes a new order from a customer and determines which servers, storage systems, and subnetworks have available capacity to host this new customer’s request for a compute or software instance. As each server and server farm fills up, the system knows to automatically move to the next pool of servers to provision new services (e.g., virtual machines).

If there are no avail- able resources, a warning message is generated to the cloud provider’s support staff. When additional space is available, the orchestrator will again attempt to provision the new service. All of this is done without human intervention, and potentially hundreds of times each day as new customers order services and existing customers begin to utilize more disk space and VMs.

 

RESOURCE RECLAMATION

The opposite of automated provisioning is the de-provisioning of services for customers that cancel, or that the support personnel instruct the cloud management system to destroy. The management system knows how to stop VMs, delete user accounts, reclaim disk storage, application licenses, and cease billing for the terminated services. When any customer’s subscription is terminated, all of the server, VM, processor, memory, storage, and other resources are cleared, reclaimed, and made available for the next customer.

There are some hypervisors and storage systems that do not automatically reclaim the now-unused disk space because of technical limitations in the manufacturer’s software. This is similar to moving files to your deleted items or trash can on a desktop computer, but the disk space is still being occupied by the deleted data until you clear the trash can; the disk space is not truly reclaimed or made available for the next customer.

 

Key Take-Away

The reclamation process, both within a hypervisor and especially storage systems, are not always automatic (various limitations of some software manufacturers). This requires the creation of batch processes scheduled to run daily, weekly, or monthly during nonpeak hours to actually clear services or data that is no longer active.

 

SETTING UP ORCHESTRATOR WORKFLOWS

As the orchestration system is essentially the brains of the cloud management system, it is also the place where any custom business logic and customized workflows are created. The cloud service provider can use the orchestrator to provision simple or multitiered cloud applications, send messages, send out customer invoices, and automatically trigger an alert for any event within the cloud. As future “as a service” products are deployed, the orchestrator is updated with new workflows, scripts, processes, and rules that facilitate automated provisioning, utilization tracking, billing and metering, and operational management. 

Many cloud management platforms include a service designer tool (through programming and/or a GUI interface) with which the cloud provider or technically skilled customer can create new workflows, single or multiple VM platform applications, network segmentation etc.

 

Often, in a private cloud deployment model, the orchestrator can be used to handle highly customized customer needs. These custom tasks could be to per- form multiple-level order approval, approver reminders after a period of time has passed, or customer notification of certain events. You can also program the orchestrator to do non-cloud-specific tasks such as opening a support ticket, gathering statistical data and sending a monthly report, or warning the cloud provider’s support personnel well in advance before they run out of available disk storage.

 

Key Take-Away

Some orchestration systems include a library of pre-integrated service designs and connectors to external software systems, hypervisors, network management tools, and additional cloud providers in a hybrid cloud environment.

 

==END