What's the difference between DevOps and Automation?

Question

I see that whenever someone does DevOps, it's mostly about automating things like deployment etc.

But where does automation end and DevOps begin?

Answer 1

A big part of DevOps is making it possible to release very often. That comes with automated build, automated testing, etc. You can say that to achieve its goals, DevOps need to use automation to be efficient.

Here's how DevOps and automation are related. DevOps is not just automation, there's more to it. Conversely, automation is not exclusively used by "DevOps people". A lot of automation was taking place in IT before DevOps came around.

Please don't consider to above diagram to represent all that is DevOps, or all this is automation. It is to help the reader picture how the two concepts are related.

Answer 2

Automation is a key attribute of DevOps, but it's not the full story. The question is kind-of like "What's the difference between time-boxing and Scrum?".

You'll hear DevOps called a 'culture', a 'movement', a 'methodology', and all kinds of things that won't box it in well enough for you to understand it, even though those descriptions are accurate. In a nutshell, DevOps is about the confluence of Agile methodologies, automation, and virtualization that enables a new feedback loop in the management/control/steering of a software project.

With aggressive automation, things that use to take a long time and be subject to human error now happen quickly and without incident. As a result, we tend to do them more often. A primary example of this is a 'deploy into production'. We used to save large batches of work and deploy them off-hours just in case 'something went wrong'. But now we can deploy changes several times a day, in a way that the chances of 'something going wrong' is dramatically reduced, and in a way that the impact of something going wrong is much smaller when it does occur.

Once we have this repeatable process in place, we begin to see it as a 'pipeline'. Requirements go in, code deployed into production comes out. We automate everything along this pipeline - tests, documentation, merges, deploys, and more tests, and so on... Because people focus on the automation, they don't see the 'pipeline mentality' that drove it. This is the management methodology - the attention paid on the pipeline - that makes DevOps more than Automation.

Once we have that automation in place, the feedback loops kick in. We start to measure things like cycle time so we can figure out things we had previous tried to guess with estimates. Things about the architecture that make automation/continuous delivery hard tend to be replaced with alternative architectural patterns that make automation/continuous delivery easier (several great examples of this are documented in the book 'Evolutionary Databases'. 'Green/Blue Deployments' are another).

Notice I was able to provide this description without talking about Jenkins, Check, Puppet, Ansible, Vagrant, AWS, or any of the other tooling that supports it. This is what we mean by the larger level buzzwords like 'methodology'. In the end, any set of tools can be replaced... What we're left with is the core management principles enabled by automation and the focus on the pipeline.

Answer 3

DevOps is really a cultural shift - it's intended to be about breaking down the traditional barriers between operations and development (and really also with QA and the rest of the business!). The idea is that rather than having departmental 'silos' you can work directly with other teams to get things done quicker and more efficiently.

It's all about removing constraints and streamlining processes. Automation comes into this heavily because having repeatable processes helps remove constraints. For example: if someone from ops has to do a manual release process to get code out to an environment, there's a couple of things that can get in the way - one is that there has to be someone in ops free to do the deploy, and two, there is less confidence in the release process because manual work is error-prone.

Answer 4

DevOps includes automation but that's only part of it. DevOps is a cultural change to break down the silos between the different parts of the organization to provide a complete value stream. Providing a culture where business, development, quality assurance, infrastructure, security, ops, etc all work together to provide value to who ever is the end user. DevOps is not a tool, you can't buy it, you have to change your culture.

Automation is a key part of DevOps in that it allows the speed of delivery with quality. Automation for the deployment process is one of the areas many people focus on first as it is one of the best ways to gain value quickly and provides a high return on investment through not only reducing the time for the deployment but also standardizing the process and removing errors.

Answer 5

DevOps movement consists of four major areas abbreviated as CAMS:

1. Culture
2. Automation
3. Measurement
4. Sharing

Here is the original defining post from 2010.

In each area there are some tools, processes and practices that are generally accepted, although the subject is not well defined for Best Practices, there are in most cases some Good Practices to follow.

Automation by itself is a bit wider subject, but in context of DevOps it is just a subset of what is being covered. Take a note that we lead with culture, although many DevOps practitioners new to the field often overlook it at their own peril and skip directly to automation.

Answer 6

I would like to add my 2 cents:
1) Automation:
     Something that we are nowadays having to move towards. It has become more of a necessity wherein the preferred way would be to automate pieces, if not the entire process. This approach gives the users (developers) flexibility to use a fixed step along with being able to customize as needed.
     The advantage in this approach is that we can automate the parts that we want to while the individual process can be tied together by the developer. The more granularized the automation steps, the better control they have.
     Also, there are many tools for automation in spaces like robotic automation, SOP automation (for servicing industry), report automation (like Splunk), etc.
2) DevOps:
     Given the state of delivery quality and timeliness that is being expected out of the current world, there is a necessity to extend automation of the software delivery process. To enable this and provide value to the customer in the fastest way possible, DevOps does extensively rely on automation tools.
     The advantage in this approach is that, the individual steps can be automated to bring about consistency across enterprise while the overall orchestration can be modified to suit the process needed by that project.
     The individual automation tools (in a way) like Chef for deployment, Docker via Dockerfile, Maven for build, etc. can be tied together probably via Jenkins to provide the required solution while at the same time bringing down the time needed for implementation or usage.
Hope this helps to add any value to the thought process that you may already have.

Edit: Forgot to add that I had talked about the Process and Tools - 2 of the 3 aspects in DevOps. As mentioned by the others, the 3rd and equally important aspect is People. One of the major differences I would assume between this and automation would be that people are more prone to absorb automation more frequently than they would resist DevOps. I feel that this is due to the nature of DevOps itself, in that automation is usually associated with making things easier for them, while they feel that DevOps is changing the way that they are comfortable with.

Answer 7

Automation and DevOps are unrelated. DevOps is more like combined engineering where the Developers of a site or service are all the Operators of that site or service. Why is this novel? In my experience the first thing the Ops team did when anything more exciting than a network blip happened was to call the Dev team. Why did they do that? Because all the Ops team did was monitor and keep a list of dev phone numbers to call.

Notice I've said nothing about automation.

Automation is about repeating success. If I do steps a,b and c and process X always works, then steps a, b and c are good candidates for automation. Then I can use the time for what used to be a manual process to do things that make me more money. Automation is successful when it's simple. Deploying new releases, running integration tests, torquing a nut on a bolt, backing up data, balancing credits vs. debits, etc. are all great candidates for automation because the steps are repeated whether by a person or a robot.

Note: What is new is that Developers are also the operators. There is not another group. Cooperation in my case was rare. If there was nothing in the Troubleshooting Guide (aka TSG) then you were guaranteed a phone call. In my experience Ops was the first call in case of backhoe. Problems between services were out of their wheelhouse.