Whether you’re a DevOps lead, Site Reliability Engineer, IT Manager, or CTO, odds are automation is pretty much ingrained in what you do.
In many ways, the terms automation and DevOps are synonymous. And in recent years, it feels like the term has taken over, as there’s almost no end to solutions that aim to automate something.
A recent report from Red Hat found that companies have automated an average of 36% of their cloud operations. The longer a business has been established, the more its manual processes have been replaced with automated workflows.
There are a variety of reasons for the rise in automation popularity:
- Companies want development operations focused on mission-critical tasks
- A desire to speed up timelines for releases
- Leaders want more agility and collaboration from teams
- Manual systems are notoriously prone to human error
- There’s more demand for IT, SRE, and DevOps roles than there are people to fill them
Automation – more than a buzzword?
Rewind recently sat down with various software development leaders about their automation experiences, how automation fits within their team’s goals, and the frameworks they use for making decisions.
Scott Sturgeon, CTO at Tugboat Logic by One Trust, is skeptical. “From my perspective, automation has become a buzzword. Not everything can be automated in a sane way. Not everything should be. Things that are repetitive and time-consuming, are the things that I tend to focus on. Most of the automation you hear about these days comes down to CI/CD –continuous integration, continuous deployment. You can build out very complex pipelines that can automatically update your production instance. Which is great, if you’re set up to do that properly.”
“I think automation is a very generic term and you want to be more specific about what you’re actually going for. It’s a technique and method, rather than an outcome,” explains Nigel Kersten, Field CTO at Puppet. You don’t automate for automation’s sake, you automate because you’re trying to achieve a result. I also think it’s a good marketing buzzword because it resonates with the folks on the ground who think, ‘I can make robots do it.’ So you have to be cautious about how you’re using that word.”
Heeding this caution in mind, here are some top tasks that are frequently over-automated or unnecessarily complicated by automation.
What not to automate
Although most tasks can be automated, it doesn’t mean they should be. Here are some quick tips on what can be removed from the to-be-automated list:
- Tasks with a low return on investment, where the amount of effort required doesn’t produce any significant returns
- User experience testing or anything where you have a subjective result
- Tasks where there’s a very high degree of unpredictability
- Tasks with a low amount of repeatability
- Tasks with no well-defined procedure/pattern
“Things that a computer can’t do well should not be automated. For example, a lot of companies try and automate code reviews,” explains Scott. “This is fine for things following syntax or weird circular dependencies. A computer can figure that stuff out. However, looking at the logic of a piece of code and whether or not that’s done properly isn’t something a computer can do well. A code review, in my mind, still requires a person to look at it.”
James Ciesielski, CTO at Rewind, expands on this risk-based approach to automation in development. “When it comes to deciding what to automate, we assess the risk of having people involved in maintaining a process. I’ve seen development environments where people were granted God-like privileges to the development team. Often this is done in the name of serving customers, but people make errors, intentional and unintentional.”
How to decide what needs automation
The reality is that many businesses will need to automate things that directly or indirectly impact their product or service. Unique use cases can arise in any environment, especially as markets become more competitive, more SaaS companies come online, and road maps get more ambitious. But as any development team on the planet will tell you, their To Do-list is impossibly long. As a team, how do you prioritize and agree on what to tackle next?
While there’s no one-size-fits-all approach to the decision, here are some signals IT experts use to evaluate whether a process is a good candidate for automation:
- Manual: Like manually running a script that automates a task. Although the script may be quicker than actually executing each manual step, the time it takes to run a script is still time that could be used elsewhere. In other words, if I have to keep pressing a button, I may eventually spend all my time pressing that button.
- Repetitive: After about the second time of performing the same task, it may need to be automated. Solving new problems doesn’t count.
- Automatable: If a machine can do the same job just as well as a human, it can be considered toil. If the task needs a human to really think about things, it may not be a good candidate.
- Tactical: If something keeps interrupting your team and pits them in “reaction ”mode, minimizing these distractions could be something to address.
- No enduring value: If you perform a task, and your product or service remains the same, it’s probably contributing to toil.
- Tasks grow as operations grow: If the magnitude of a task increases as service size, traffic volume, or user count— it’s likely an issue.
In the end, often a good starting point is finding processes (which add value) that you are frequently doing and relying on a human. When people are involved, the chances of error go up exponentially.
Lena Feygin, DevOps Team Leader at OwnBackups, stresses caution and prudence over the desire to ‘:automate_all_the_things:.’ Her advice? “In the end, we only need to automate issues that really cause problems and not fix problems that don’t exist.”
Looking for more expert advice on automation from DevOps pros? Download our complete guide to automation in development operations- absolutely free.
James Ciesielski">
