alt

 

I am always asked why choose orchestration over scripting. The short answer is that orchestration has a lot more to offer; the long answer is below.

I started to work in IT in 1995 after getting my analyst-programmer degree. Naturally I used scripted automation right away and never stopped since then. I have used batch, shell, vbscript, kix, perl and various other scripting languages to automate desktop and server automated provisioning and operations in physical and then virtual environments in the early 2000s. With such a profile I joined a Swiss orchestration start-up on a Wednesday and delivered my first workflows the week after ... I have provided such workflows to large service providers and enterprise customers that are running them in production. Orchestration became my most important tool and I can not imagine automation anymore without it.

Scripting people have preferences for different scripting languages such as JavaScript, Perl, PowerShell, Python. Each of these have advantages and drawbacks. All of these are used in one way or another at VMware and we provide SDKs supporting these. vCenter Orchestrator uses JavaScript for his scripting engine. Javascript has a simplistic syntax and is widely used for web pages interaction and web apps (HTML5 and Flash).

The specific value of a scripting language versus another is, in my opinion, irrelevant as long as you can get to the same result with a similar effort. It took me a few days to go from Perl to a JavaScript level good enough to do what I needed.

What is making a big difference is the orchestration platform around the scripting engine and how it will help the different actors in the business including the different actors developing, operating and using the solution.

For the end Users

vCenter Orchestrator workflows span across IT departments and can delegate operational procedures to the end user.

  • To do this the workflow engine implements security access control with setting permissions on different workflows or even different parts of the same workflow. Some operations can be run as the user while others can run as service accounts.

The end user can use workflows with a web front-end either directly through the web views or indirectly through the web service which includes:

  • Presentation forms with content validation. This allows to run scripts to control inputs as they are typed, manage dependencies between fields, calculate defaults.
  • A real time inventory of all orchestrated objects providing single sign on capabilities, a cache mechanism and automatic updates.
    This provides a single pane of glass across all the systems allowing the end user to select object and check their main characteristics before submitting a workflow.
vCO Inventory
VSM Inventory
vCenter Orchestrator
Webview inventory
Service Manager CMDB linking diagram
leveraging Orchestrator Inventory

 

For the system administrators

High availability:

  • A workflow can resumes where it stopped if the vCenter Orchestrator host fails
  • vCO can fail over to another vCO server and fail back

vCenter Orchestrator is a stateless workflow engine server. All the process flows and data flows are stored in a database.

Compliance:

  • Each workflow has a life record containing start, end time, state, inputs, outputs, variables that can be used during or after execution
  • All workflows have events that can trace all the operations information, warnings, errors
  • The Log4J facility allows fine grained monitoring configuration
  • All the workflows are centralized and versioned. No scripts scattered across all the orchestrated entities.

Ease of understanding / development / maintenance:

  • Out of the box VMware supported workflows: vCenter Orchestrator plug-in library contains several hundreds supported open source workflows.
  • No need to have script experience to understand what the sequencing, the logic and operations in a workflow. A workflow can be understood by management.
Workflow Example
vCenter Orchestrator Workflow example

For the workflow developer

  • It is much easier to troubleshoot / maintain / modularize - reuse workflows than scripting : As an example: Before using vCenter Orchestrator I had spent a large effort on a very long script to handle site disaster recovery. It was difficult for me to troubleshoot and maintain it particularly when I had to do it a few months after the first time I put it in production . With vCenter Orchestrator I delivered something similar to the Perl script, except I did it in one week and it was multithreaded and load balancing the VM copy operations on different ESX servers. I reused part of this workflow in several occasions and I have met with the customer years after delivery: he was still running it and had done his own changes / improvement on it).

 

  • Workflow development studio:
    • vCenter Orchestrator drag and drop workflow development environment with its library of modular, re-usable workflows
    • API explorer: A single interface to check all orchestrated objects and methods.

 

  • Content life cycle management:  vCenter orchestrator provides -
    • A packager managing dependencies: This allows simple distribution of a set of functionality you need to deliver to your customer.
    • Version history: This allows to manage workflow versions when shared across different packages or synchronized across vCenter Orchestrator servers.
    • Signed Certificates and Digital Right Management: This allows you to protect the workflows you have developed against changes, redistribution or copy of the source code.
    • Synchronization: Synchronize the workflows, packages across vCO servers. Need to move workflows from dev to test or test to pre-prod. Synchronization do it automatically for you.

vCO Synchronization

Content synchronization between vCenter Orchestrator servers

 

  • Environment abstraction: server specific configurations elements allows to copy a workflow from a vCenter Orchestrator server (i.e Development / test environment) to another one (i.e customer prod) and it automatically uses the specific environment it performs operations on or use specific settings for this environment.
Config Element
vCenter Orchestrator Server specific configurations example
  • Resources centralization:  File resources can be loaded in vCenter Orchestrator and be used from there making them highly available (vs having them in a filesystem somewhere). For example a registry file can be stored for being applied to a VM post installation.
  • Custom properties: Attach key, value pairs to any orchestrated object. This allows to extend each object with custom properties allowing their lifecycle management.

 

Superior Cloud Orchestration

 

Designed for the cloud

  • vCenter Orchestrator is java based and as a "natural" integration with Java / Spring. vCenter Orchestrator Customers build their own plug-in leveraging their java code.
  • vCO is platform independent, it can run on its own in a virtual appliance.

 

A clear choice for the most demanding customers

  • Large service providers use vCenter Orchestrator as their cloud workflow engine (i.e T-Systems presentation at VMworld and I know at least two others do).
  • Enterprise customers use it for their private cloud, integrations, virtual infrastructure and cloud lifecycle and operation automation.

 

Already installed

vCenter Orchestrator was installed as part of the vCenter Installation. It is waiting for you to take advantage of it for free with configuring it as did thousands of VMware customers.

 

Does not prevent you from using other scripts

vCenter Orchestrator can start external command lines, SSH or use SOAP / REST. The scripts can be centralized as resource files in vCenter Orchestrator to benefit from high availability.

 

OK, great but how much ?

An advanced orchestration engine, plug-in adapters, library of workflows cost a fortune compared to a scripting engine. vCenter Orchestrator is coming free with vCenter.

 

alt