Automation has evolved from its humble beginnings as a local basic scheduler kicking off scripts and tasks into an enterprise-level tool used in most, if not all, of the unique silos that encompass corporate IT. In this article, I focus on some of the different kinds of automation engines that are in use. This post will not even begin to touch on all of the different products and solutions that are out there, and I certainly won’t claim that there is any one right way or tool. However, I would like to go on record to say that, in my humble opinion, there is one primary wrong answer with automation, and that wrong answer is to be completely dependent on any one solution or product itself.

Truth be told, the orchestration engine that is used is completely dependent on the type of environment being supported. The main reason for that is that in a great number of platforms, the orchestration engine usually comes as part of an overall solution. If you happen to be using VMware as your hypervisor, once vCenter Server is licensed, then you are fully licensed with VMware vRealize Orchestrator (vRO). On the flip side of that coin, if you are running a large Microsoft shop and are using Microsoft’s System Center to control and manage, you could be using any combination of Microsoft Orchestrator, Service Management Automation, and/or Azure Automation. If you are mainly a Linux shop, Ansible could easily be your automation engine of choice.

There are several different options available, and there is no one right answer. Rather, what is important is giving teams the option to work with a solution or product that the teams are used to, as well as being able to take advantage of the different engines that are included as part of other solutions. It doesn’t matter how many different orchestration engines are used. What does matter in today’s world is that any solution or product has an application programming interface, or API. As I mentioned in my last article, finding a better way to fully open up communication and cooperation between different silos is going to be key. This could mean some kind of project manager or core technology group that could provide a foundation for a DevOps-type mentality. APIs easily make the handoff or transition from one team to another seamless and usually flawless. Once one technology silo finishes its part of the automation, the workflow makes a call to the next system and provides the information needed for the automation to continue. This kind of API connection is also referred to as “web service interactions.” As you add more web service calls to the workflows, you are really establishing coordination from a global multi-participant perspective without an overall central controller. We could refer to this as “service choreography.”

Unfortunately, since service choreography doesn’t have any kind of centralized management or monitoring of all the different web services and the overall status of the workflow, it limits your ability to fully enhance and establish a solid exception routine that can take advantage of all the web services that are connected. For that reason, you need to find a solution to manage and control the complete workflow and coordination of all the web services’ calls and returns, instead of following the choreography model in which the workflows are independent. In this type of model, if one technology solution—CMDB, for example—is replaced by another product, then only the module that makes the call to the CMDB needs to be replaced with modules pointing to the new solution. This will help bring the Agile application model to the orchestration.

In closing, I’d like to reiterate that multiple orchestration engines are a positive for overall corporate automation structure and design. There is no single right answer, and as such, no single orchestration engine should be used. Rather, take advantage of any and all automation tools from all vendors at your disposal. You will get more functionality and better overall results by taking advantage of tools and workflows provided by the manufacturer. Could any other company automate Microsoft products and solutions better than Microsoft? Could anything automate the VMware infrastructure better than its own products? Take advantage of it all to bring your orchestration in the twenty-first century data center to life.