Automation And Orchestration: Speed Vs. Efficiency

Any discussion of DevOps or SDN is almost certain to devolve to a discussion around automation. Early on, this frustrated proponents of DevOps because the premise of DevOps is that it’s an approach, not a tool, technique or technology. But the reality is that those who live in the trenches are doers and implementers and thus while the business and cultural aspects of DevOps and SDN are interesting, they’d really rather get down to doing.

But even the topic of automation isn’t as clear cut as you’d think. Too often we say automation when we mean orchestration -- and vice versa. Of course the question that usually pops up after that is, “Does it really matter?”

If we’re going to pull off all this “IT as a service” then yes, it does matter. The line between automation and orchestration is the demarcation between SDN and DevOps, between operationalizing the network and operationalizing the production pipeline.

Automation is about tasks. Its focus is on using scripting, frameworks, APIs, and templates to programmatically achieve the deployment (configuration) of a network service. Setting up a new VLAN? Automate it. Configuring the load balancer or firewall? Automate it. Automate the heck out of those tasks that are risky and time consuming as a way to realize greater stability, reduce risk, and lower operating costs. These are the most sought-after benefits of SDN and drivers of its adoption.

But that isn’t orchestration, which is the automation of processes.

If we look at DevOps as put into action with continuous delivery (CD) or continuous integration (CI) we’ll see the difference immediately. Each “step” in the lifecycle has some automation tasks associated with it -- build, test, deliver. Building a piece of software isn’t the same as running it through a set of tests isn’t the same as delivering it up to be deployed.

Each of those steps is automated, but the bigger value is the orchestration of the entire process. The handoff from build to test to deliver is a process with gates that are (hopefully) clearly defined. If build passes, the software goes to test, and so on. If it doesn’t, the process routes the appropriate information to those who have to try again.

Perhaps that orchestration is just another script, automatically generating the right email or submitting tickets or defect reports to a system that will then generate an email or a Slack message. The "what" isn't as important as the understanding that orchestration is about coordinating the tasks that make up a process and enabling the collaboration critical to success with a DevOps approach.

The same is true for the production pipeline. There’s a process that’s required to "move" an app from one end to the other, to the ultimate consumer. There are storage and compute resources that must be provisioned and configured. The app must be deployed. Network and security services need to be provisioned, configured, and, yes, tested.

But there’s a well-defined order of operations (if you’ll pardon the pun) that must be followed. You don’t deploy services dependent on network topology before the network is ready. You don’t deploy the app before its compute and storage is ready. And so on. That’s process, and that’s the role of orchestration.

It’s absolutely a good thing to automate tasks, but it’s also important to orchestrate processes. That’s because in doing so, you’ll bring to the surface those interfaces between groups (silos) and tasks where inefficiencies can be rooted out and eliminated because you’ll be able to measure the process in terms of time spent not only per task but between tasks.

It’s critically important that we not stop at network automation and congratulate ourselves on improving the path through production for applications. We haven’t finished until we’ve not only automated the processes that take an app through the production pipeline (orchestration), but optimized it by eliminating the inefficiencies in the process.

Automation is without question the right place to start. But recognize it’s only the first step. Once tasks have been automated, then they can (and should) be chained together as part of the larger production pipeline process. Automation is more about stability, consistency, and costs than it is efficiency. You'll find the efficiency needed to improve time to market and get the network “out of the way” when you go beyond automation, into the realm of orchestration.