I was given a few more (huge) tasks to automate with my wrapper API, and as I began to setup a production system I came to a realization. I'm one of roughly three people on my team who know Linux relatively well, and the only one who knows Ruby even a little. Hanging multiple production system integrations on a Ruby based API residing on a Linux box is probably not a great idea.

So I scrapped all of that Ruby wrapper stuff (for now). Searching for an alternative, I fell back on a familiar tool for automation.

VMware Orchestrator

VMware's vCenter Orchestrator (vCO) is Windows based (great for the majority of my team who are most familiar with that OS), comes with three methods of interaction (fat client, API, web interface), is already in production use for some Implementation tasks, and is extensible through multiple plugins. As long as we have at least one vCenter server under VMware maintenance, the vCO server is licensed and covered with support. Initial concerns about tying everything to VMware can be assuaged through two key plugins: HTTP-REST and SOAP. With these two plugins, Orchestrator can integrate with any third party SOAP/REST API.

Registering a SOAP/REST API service URL is very easy - for SOAP, vCO will automatically import a WSDL, REST can have calls added manually or the register workflow can be provided with a XSD schema. After the hosts are registered and calls are defined (either manually or via WSDL), it becomes trivial to incorporate those API calls with normal vCO workflow. Both API plugins contain a "Generate new workflow from a REST|SOAP operation" workflow that will create individual workflow objects with the proper input fields and output fields required for each API request. The input/output can then be parsed using javascript to create complete workflows.

Example of Generated Workflow:

Example of Complete Workflow:

The Good

• Utilizes an existing platform with 24x7 support and pre-existing automation elements.
• Very simple/intuitive way to integrate multiple workflows and APIs.
• vCO offers scalability with

The Bad

• I'm not sure what's not to like about this... maybe that it's closed source?
• With our current authentication method (SSO tied to vCenter), API calls require an initial authorization call to vCenter and the retrieval of an auth token.