= What's the difference between orchestration and automation

For the longest time, it seemed all any sys admin cared about was automation.
Recently, though, the mantra seems to have changed from automation to orchestration, leading many puzzled admins to wonder "What's the difference?"

The difference between automation and orchestration is primarily in intent and tooling.
Technically, automation can be considered a subset of orchestration.
While orchestration suggests many moving parts, automation usually refers to a singular, or a small number of strongly related, tasks.
Orchestration works at a higher level, and is expected to make decisions based on changing conditions and requirements.

This view, however, shouldn't be taken too literally, because both the terms _automation_ and _orchestration_ do have implications when used. 
The results of both orchestration and automation are functionally the same: things happen without your direct intervention.
But the way you get to those results, and the tools you use to make them happen, are different, or at least the terms are used differently depending on what tools you've used.

For instance, automation usually involves scripting, oftentimes in Bash or Python or similar, and it often suggests scheduling something to happen at either a precise time or upon a specific event.
Orchestration, however, often begins with an application that's purpose-built for a set of tasks that may happen irregularly or on demand, or as a result of any number of trigger events, and the exact results may even depend on a variety of conditions.


== Decisionmaking and IT orchestration

Automation suggests that a sys admin has invented a system to cause a computer to do something that would normally have to be done manually.
In automation, the sys admin has already made most of the decisions on what needs to be done, all the computer must do is execute a "recipe" of tasks.

Orchestration suggests that a sys admin has setup a system to do something on its own based on a set of rules, parameters, and observations.
In orchestration, the sys admin knows the desired end result, but leaves it up to the computer to decide what to do.

Consider Ansible and Bash.
Bash is a popular shell and scripting language used by sys admins to accomplish practically everything they do during a given work day.
Automating with Bash is straight forward: instead of typing commands into an interactive session, you type them into a text document and save the file as a shell script.
Bash runs the shell script, executing each command in succession.
There's room for some conditional decisionmaking, but usually it's no more complex than simple if-then statements, each of which must be coded into the script.

Ansible, on the other hand, uses _playbooks_ in which a sysadmin describes the desired state of the computer.
It lists requirements that must be met before Ansible may consider the job done.
When Ansible runs, it takes action based on the current state of the computer compared to the desired state, based on the operating system of the computer, and so on.
A playbook doesn't contain specific commands, instead leaving those decisions up to Ansible itself.

Of course, it's particularly revealing that Ansible is referred to as an automation, not an orchestration, tool.
The difference can be subtle, and the terms definitely overlap.


== Orchestration and the cloud

Say you needed to convert a file type that's regularly uploaded to your server by your users.

The manual solution would be to check a directory for uploaded content every morning, open the file, and then save it as a different format.
This solution is slow, inefficient, and probably could only happen once every 24 hours because you're a busy person.

You could automate the task.
Were you to do that, you might write a PHP or a Node JS script to detect when a file has been uploaded.
The script would perform the conversion and send an alert or make a log entry to confirm that the conversion was successful.
You could improve the script over time to allow users to interact with the upload and conversion process.

Were you to orchestrate the process, you might instead start with an application.
Your custom app would be designed to accept and convert files.
You might run the application in a container on your cloud, and using OpenShift you could launch additional instances of your app when traffic and workload increased beyond a certain threshold.


== Learning automation and orchestration

There isn't just one discipline for automation or orchestration.
These are broad practices that are applied to many different tasks across many different industries.
The first step to learning, though, is to become proficient with the technology you're meant to orchestrate and automate.
It's difficult to orchestrate (safely) the scaling a series of web servers if you don't understand how a web server works, or what ports need to be open or closed, or what a port is.
In practice, you may well _not_ be the person opening ports or configuring the server; you could be taksed with administrating OpenShift without really knowing or caring what's inside a container, but basic concepts are important because they broadly apply to usability, troubleshooting, and security.

You also need to get familiar with the most common tools of the orchestration and automation world.
Learn some https://www.redhat.com/sysadmin/using-bash-automation[Bash], start using https://opensource.com/life/16/7/stumbling-git[Git] and design some https://opensource.com/life/16/8/how-construct-your-own-git-server-part-6[Git hooks], learn some Python, http://link/to/a/yaml/article/by/me[get comfortable with YAML] and https://opensource.com/downloads/ansible-k8s-cheat-sheet[Ansible], and try out Minikube, https://www.redhat.com/sysadmin/learn-openshift-minishift[OKD], and http://openshift.io[OpenShift].

Orchestration and automation is an important skill, both to make your own work more efficient and as something to bring to your team.
Invest in it today, and get twice as much done tomorrow.

