• 03/20/2015
    7:00 AM
  • Rating: 
    0 votes
    Vote up!
    Vote down!

Cloud Orchestration Vs. DevOps Automation

Confused by all the buzzwords around cloud and DevOps? Here's a breakdown of terminology to try to get past the hype.

The rise of cloud computing and DevOps has spawned a lot of buzzwords, along with a lot of confusion, disdain and rhetorical debate over terminology. In this blog post, I'll take a crack at teasing apart these terms and hopefully provide some clarity.

First off, let’s examine the difference between orchestration vs. automation.  These two terms are often used interchangeably, and are often confused.  The confusion is most likely about semantic hierarchy, because while it's true that orchestration is in one sense just a specialized form of automation (and therefore a sub-category of automation), functionally speaking, orchestration is a “higher form” of automation because it's concerned not just with simple or lower-level tasks, but with control and coordination of multiple component automation tasks. 

Now let’s look at the relationship between DevOps and cloud. DevOps describes a culture of technical collaboration between teams from development through IT operations to drive more agile software development lifecycles (SDLC) that result in higher quality software outcomes. Cloud describes a way of managing and consuming infrastructure (and other resources) such that it is self-service, elastic, Internet-accessible and automated. 

Since DevOps is the higher order, end-to-end concept, we can consider cloud at least in the context of this discussion, to be a subordinate enabler of DevOps.

Figure 1:

Perhaps it's best to mix and match these terms to decrease any possible ambiguities.

Cloud automation.  Discrete automation tasks or objects that perform needed aspects of deploying cloud resources.  These tasks could be things like spinning up a bare metal server or a VM, installing an OS image, and deploying an application or network function.  Cloud automation tasks can be performed by a variety of automation tools such as homegrown scripts, configuration management tools.

Cloud orchestration.  End-to-end automation workflow or process that coordinates multiple lower-level automations to deliver a resource or set of resources “as a service.”  Cloud orchestration is typically delivered by a cloud management platform (CMP) that includes a number of layers of functionality:

  • API and web portal/catalog access
  • A service management layer that presents service offerings and allows users or automation processes to customize those service offers in real-time before deploying.  The services may be completely consumption oriented (an end-user service catalog), or also allow dynamic service design, infrastructure modeling, live sandboxing, etc.
  • An orchestration layer handles the control, governance, coordination aspects of the service delivery processes.  It interacts via abstractions with underlying resources.   Note that in most cases, this layer’s logic is fairly fixed or is not really exposed to the CMP users.  However, some CMPs offer integrated orchestration authoring and some provide that orchestration in a visual form.
  • A resource management layer that handles open and abstracted interfacing to all resources whether they be bare metal servers, networking, virtualization, services, applications, etc. 

DevOps automation.  Discrete automation functions such as build, continuous integration, software configuration management tools.

DevOps orchestration.  Automated coordination of an organization’s custom-defined DevOps process and the automation tools and tasks they carry out in that process.

Now that we’ve hopefully clarified some of the terms, how in fact does cloud infrastructure play along with DevOps automation tools, and how are they orchestrated or coordinated to support a desired process? 

A good way to think of it is when developers and testers need to access multiple VMs and perhaps even a bare metal server and some networking switches in order to work on an application.  In this case, all that cloud infrastructure needs to be allocated, connected and configured as a working environment, and that requires cloud orchestration because it requires coordination of automation working on top of all those VMs, servers and the networking in a particular order. 

Orchestration can then go beyond just pulling the cloud infrastructure together to encompass DevOps automation tasks in coordination with that infrastructure. Now you’ve got DevOps orchestration.


Ideal Tool & Ideal Situation ???

I really think if we have Ideal Tool to handle complexity in a cloud environment because it involves interconnecting processes running across systems in multiple locations. After this it becomes even more complex with processes and transactions which need communication across multiple systems and firewalls.

Re: Ideal Tool & Ideal Situation ???

Yeah, there are plenty of ways to make orchestration more complex--security and other policies, ability to choose resources based on proximity, cost, etc.  What do you consider to be something that's close to an ideal tool?

Re: Ideal Tool & Ideal Situation ???

Orchestration is critical in the delivery of cloud services, as key part they are intended to scale-up dynamically, without requiring any manual intervention to do so, before going with orchestration you need to understand and define your golas very clearly.

Re: Cloud Orchestration Vs. DevOps Automation

"These two terms are often used interchangeably, and are often confused." This is definitely far too common an occurence in IT. I think a whole website could be made solely dedicated to writing articles correcting this kind of conflation, and it would have plenty of content to keep it going for a good long time. Sometimes I think it's a conscience effort on our part to keep up the mystique of IT so users will continue to think we're miracle workers - if nobody can understand what the heck we're talking about, that's pretty good job security. To that end, though, I'm not sure if the way you've lined things up here is quite suitable for end users who have no base definitions of these terms to begin with (not sure if that was your intention or not). I'm worried it's more suited to those who already know most of this to nod their heads in agreement.

do think you make a strong case for the obvious synergies between cloud, automation, and DevOps. For those already well-read on each topic wondering if and how a combination is the next big step for them, what you have here should give them a template they can apply to their own business to see if it's a fit. This can give them some ammo to bring to the table for or against it when they sit down to talk with management. For example, a strong need for self-provisioning from the development side needs to be there to warrant this level of upfront effort by IT. I hear about containers (re: Docker) a lot when it comes to fast-paced software development - how do you think that fits in here when combined with cloud and automation? Does it all go together, or is it more of a 'this-or-that' situation?

Re: Cloud Orchestration Vs. DevOps Automation

Thanks for your comments and feedback.  You're right in the sense that I'm speaking to those who already have at least enough familiarity with the automation/orchestration concepts to have wondered about it, rather than just accepting them as another pair of mystery box terms.  For less technical folks for whom we need to truly translate terms, that requires a different level of articulation for sure.

Regarding containers, there is a certain amount of polemics happening in the industry now about how they're going to eat VMs, etc.  I see containers as a helpful and complementary application portability tool/technology that is agnostic to whether the self-service cloud infrastructure includes a hypervisor or not.  VMWare and AWS have cozied up to Docker pretty heavily, and I think its pretty unlikely that we suddenly see enterprise IT datacenters tearing out their hypervisor/virtualizatin layer since after all that has delivered a great ROI.  I think its much more likely that the virtualization and cloud layer gets alot more open source-based (OpenStack/KVM), though there will be plenty of ESX and Hyper-V left, just like Linux penetrated deep but there's tons of Windows still left. 

I hope that's a helpful answer, and happy to hear more of your thoughts.  Much appreciated.