Analysing the differences between cloud orchestration and cloud automation


What is the difference between cloud orchestration and cloud automation? An exploration of these two terms is more than a vocabulary exercise; it highlights a key challenge for teams looking to improve IT processes.

In most situations, cloud automation describes a task or function accomplished without human intervention. Cloud orchestration describes the arranging and coordination of automated tasks, ultimately resulting in a consolidated process or workflow.

It is simplest to see this in an example. To create a standard process to spin up an environment to host a new application, IT teams need to orchestrate several automated tasks: they can automate the addition of new instances during an auto scaling event with auto scaling groups, elastic load balancers, alarms, etc; the environment might also include a deployment automation tool like Code Deploy; Puppet scripts might automate the configuration of the OS; etc. All of these functions are cloud automation processes.

These automation tools must occur in a particular order, under certain security groups/tools, be given roles and granted permissions. In other words, engineers must complete hundreds of manual tasks to deliver the new environment, even when the building blocks of that environment are automated. This is where cloud orchestration is key.

Orchestration tools, whether native to the IaaS platform or 3rd party software tools, enumerate the resources, instance types, IAM roles, etc. that are required, as well as the configuration of those resources and the interconnections between them. Engineers can use tools like AWS CloudFormation or VMware’s vRealize Orchestrator to create declarative templates that orchestrate these processes into a single workflow, so that the “new environment” workflow described above becomes a single API call.

Cloud automation describes a task or function accomplished without human intervention. Cloud orchestration describes the arranging and coordination of automated tasks, ultimately resulting in a consolidated process or workflow.

The creation of these templates is time-consuming and challenging. However, whether the IT team is small and needs such tools to multiply and preserve manpower, or the IT team is very large and needs to maintain a single source of truth, security configuration, and approximate cost per deployment across multiple teams, orchestration tools both simplify and de-risk complex IT processes.

How does orchestration relate to DevOps? Essentially, well-orchestrated IT processes enable and empower continuous integration and continuous delivery, uniting teams in the creation of a set of templates that meet developer requirements. Such templates are in many ways living documents that embody DevOps philosophy. Automation is a technical task, orchestration is an IT workflow composed of tasks, and DevOps is a philosophy that empowers and is powered by sophisticated, orchestrated processes.

As is already obvious, orchestration has the potential to lower overall IT costs, free up engineering time for new projects, improve delivery times, and reduce friction between system and development teams. However, every enterprise is in a different stage of implementing the tools and the philosophy orchestration implies. Some organizations have only begun the cloud automation process, and smaller organizations may still rely on a single individual or team to be the orchestration “brain” that is coordinating IT processes. (One can imagine what happens when this individual or team leaves the organization.) On the other end of the spectrum, organizations that orchestrate automation tasks into standard but flexible IT workflows under a single monitoring and orchestration software interface are true DevOps shops.

The post Cloud Orchestration vs. Cloud Automation appeared first on Gathering Clouds.

Related Stories

Leave a comment


This will only be used to quickly provide signup information and will not allow us to post to your account or appear on your timeline.

27 May 2015, 3:03 p.m.

+1000 on the explanation, thanks for sharing.
The approach we've taken for orchestration at Canonical (Juju, is cloud/technology agnostic. Blueprints (or bundles) written in Juju language allow for deployment on any public cloud (AWS, GCE, Azure, Joyent, Softlayer...), private cloud (OpenStack), bare metal, containers, vagrant without any code overhead.
With Juju, we've reduced deployment time of OpenStack down to 20min. We're now expanding into Big Data, HPC and enterprise workloads. Ping me to know how your platform could be blueprinted.