With use of the cloud comes the ability to use as many resources as needed, essentially endless resources on demand, using a “pay-as-you-go” model.  In a world where everything is dynamic and IT environments are constantly changing, this is becoming an ever-growing necessity.

In order to take advantage of the promise of the cloud, the migration process needs to be as painless as possible, both from a cost and resource perspective.

We have heard the terms “DevOps” and “infrastructure automation” more than once in the last year or two, and yet even today, infrastructure automation is mostly focused on setup and deployment of complex systems.

A typical deployment is usually comprised of a number of artifacts that include configuration management, monitoring configuration, custom scripts to deal with availability, SLAs, integration with third-party components, and networking.  All of these moving parts lead to a high degree of complexity.

For example,  when deploying an application to the cloud, the steps of provisioning the cloud resources would likely be automated, followed by installing the right components on top of these resources.  This not only saves time and reduces costs, but also eliminates the risk of human error.  It has been proven time and again that the impact of human error on manual provisioning has been the result of multiple outages of mission-critical services over the course of the last few years.  And if we look at the numbers, just one hour of downtime for Amazon in January 2013 cost them nearly $5 Million in revenue. (See “Amazon just lost $4.8M after going down for 40 minutes,” Geek Wire, August 19, 2013.)

When thinking about configuration management and orchestration most people have tools like CloudFormation, Chef or Puppet in mind. These tools do a great job of allocating and configuring infrastructure resources. But in reality, when deploying and managing complete application stacks, there is much more to it. Things need to be done in a certain order; there are dependencies to consider and information to share between application tiers, and then there is everything related to post deployment - recovering from failures, scaling and continuously deploying code, just to name a few.

This is where the difference between cloud automation and cloud orchestration comes in.  When we speak of automation, it is usually in the context of tasks, whereas orchestration refers to the automation of processes and workflows.  Essentially, orchestration comes in to play to automate the automation-  the specific ordering of automated tasks across tiers and machines, especially where there are diverse dependencies involved.

So, after going through the steps of automating the infrastructure provisioning, the next step is to orchestrate the startup of the various components. Take even the simplest application that has a web server and database. After installing and configuring everything, it would first need to be confirmed that the database had started, and only then move to the web server.   Specific runtime information from the database would also need to be propagated to the web server, such as the database's host and port. This stage, for the most part, is where most automation processes focus today.

At the most basic level, orchestration is a higher form of automation, which helps setup all the pieces that are related to the application, starting from the infrastructure (VMs, networks, block storage volumes, security groups, etc.), to the platforms the app runs on (database, web server, etc.), and all the way up to the application modules and code. This entire setup is often referred to as a topology.

TOSCA, (Topology and Orchestration Specification for Cloud Applications), an emerging standard for cloud orchestration which has been adopted by OpenStack for their cloud orchestration framework Heat, is a great reference in this regard. The role of an orchestration framework is to materialize a certain topology. More advanced orchestrators go beyond materializing the topology, and change it to meet the current workloads and needs of the application.

At the end of the day, it is not just a matter of deploying the application to the cloud and forgetting about it. What happens after that? If the deployment or environment is under heavy loads or experiencing peaks, how can SLAs be maintained? What happens if there are too many machines? How can deployments be downsized without adversely affecting customers and users in the process? Cloud orchestration tools help to manage post-deployment through built-in management, logging and monitoring capabilities, as well as the built-in workflow for automating failover and auto-scaling processes.

An example of the way this works, Cloudify, an open source cloud orchestration framework, consolidates all of the different artifacts into a single blueprint, which then becomes the "single-source of truth" for the entire stack.  Cloudify then parses that blueprint and executes the definitions defined therein through a single command to create a fully consistent environment - for example between staging and production.  This includes the configuration, application binaries and all its dependencies, as well as post-deployment SLAs. This provides a single-source for updating changes to the application blueprints and the SLAs themselves, such as updating, monitoring and management metrics, high availability policies, failure detection policies and configuration changes.

Monitoring and log gathering are essential elements of any running app, so they should be an integral part of the orchestrated application topology. Since the orchestration process is topology aware, it can wire and configure monitoring for the application components very easily, which is one of its greatest benefits. Going through these processes without a global view of the topology can often be time consuming and error prone. Moreover, as the topology changes, the monitoring tools would need to be reconfigured and rewired.

Having this single-source is that which facilitates continuous delivery and deployment processes from staging through production.  It consolidates tooling across teams, and the build process can then be consolidated into a single build pipeline that is agnostic of the technology stack and language runtime through custom commands.  These custom commands enable continuous interaction with a live system in the post-deployment phase, for upgrades and shipping of new code to production.

Bottom line, deploying applications to the cloud does not end with the simple automation of configuration and provisioning.  You need to know what is going on with your app at all times to be able to maintain your SLAs, increase agility and reduce costs.  It is not just about deployment automation, but it is also about cloud management.  And that is where a good orchestrator comes in.

The real long-term benefit of using a cloud orchestration tool is to manage post deployment through built-in management, logging and monitoring capabilities, as well as the built-in workflows for automating failover and auto-scaling processes – which all eventually leads to faster rollouts and improved TCO.