4 IT automation myths dispelled

In my career as a DevOps engineer, I have spent hundreds of hours automating numerous mundane tasks. Whether you are just beginning to use automation or already have some experience, you may run into resistance due to many common IT automation myths. I'd like to address some of these myths based on my experience.

Myth 1: Automating a task takes more time and effort than it's worth

If it takes more time to automate a certain task than simply to accomplish the job manually, it is not worth automating.

You are likely to get resistance from your peers or management about automating tasks based on time savings. In reality, every job you do as an engineer is worth automating, but you have to be cognizant of the time and deliverables. When certain tasks appear to be not worth automating, I have often found that what is actually meant is that it's just not possible to automate it at this time. However, in the future, your objective should be to automate the task—you are likely to get less resistance from your team if you keep this perspective. Just make sure to communicate the automation proposal in a way that meets your immediate goals and improves future effectiveness.

[ Download now:  A system administrator's guide to IT automation.]

Myth 2: You don't need to automate a one-time task

I only need to do this once, why should I bother automating it?

This is probably the biggest myth I have seen during my career.

Here's a real-life example: A product customer raised a specific issue, and it needed a particularly complex setup. The person working on the task asked my fellow DevOps team members and me for help. We did our best to automate the task we were asked to do. The task owner did his verification and then asked if we could keep it up and running for a little while. And that "little while" quickly went from days to weeks to months.

We then received another request to tweak a virtual machine (VM) instance, then a follow-up request to create a snapshot, and eventually a clone of the VM. Once the VM was cleaned up by automation, they needed to set it up all over again.

Every time a new request came up, we kept asking the person to automate it, but we were met with resistance from the individual and management because they considered it a one-time-only task. It was technically one time only, but it was a lot more effort than that. Had they approved more time automating it upfront, they could have saved a lot of time for themselves and us.

Every time they needed to make a change, they could have noted it as part of an update to their automation and made everyone's lives easier. This is just one such example. While it is sometimes hard to know how much work will be involved in solving a problem at the beginning of a project, it is essential to step back at an appropriate time and evaluate whether you need to invest in automation—before it's too late.

Skip to the bottom of list

Image

Download now

Myth 3: Automation breaks, so don't waste time doing it

It is not worth investing time in maintaining automation; it breaks often.

It’s true that automation breaks periodically as the various scripting languages change over time—or the system you interact with through the automation deprecates or introduces features.

But does that make your automation effort worthless? Not necessarily. I have often experienced this first-hand when we used automation to build Red Hat Virtualization environments. The automated tasks were initially designed for version 4.2, but we were soon upgrading to build on the 4.3 and 4.4 versions.

We kept tuning and tweaking our automation and handling the various scenarios and quirks of each version. The results were a versatile combination of Red Hat Virtualization deployment automations that acted as engines that, when fueled with appropriate inputs for each of the versions, produced fully deployed and configured Red Hat Virtualization environments.

Did I spend time debugging and fixing the automation? Yes. But I definitely found the effort worth it every time I had to rebuild the Red Hat Virtualization environments. We had six to seven environments, each with its own version, sizes, and other characteristics. Whenever new builds became available or an environment became stale due to abuse during testing, it just took a single button click to reprovision the resource.

Automation maintenance empowers you with confidence. While maintaining automation is time-consuming, in my experience, it has been more effective than I initially thought. And all things considered, what IT work doesn't include maintenance?

Myth 4: It is impossible to automate this task

It is tough to automate this; it just can't be done.

There are times when you are faced with specific processes that are more difficult to automate than you'd hoped. It is not uncommon for you to hear from your peers (or read on the internet) that a given task is just too tough to automate—nobody has ever done it, and it probably can't be done.

I ran into that situation early in my career when I was automating various infrastructure tasks. I lacked experience, and others told me it couldn't be done. My boss at the time still wanted me to pursue the challenge. His willingness to give me more time on the problem, acknowledging that it was tough, gave me additional motivation.

After spending about a month exploring options and trying various methods to create proofs of concept, I saw that I could "semiautomate" the task under the given constraints of the situation, meaning there were a few manual interventions. So it was indeed tough, but it was still a myth that it just can't be done. It takes determination and courage to go after a tricky automation problem.

Here's another perspective: If it has never been done, you invent something new. And that's what I did. The more experienced people were right: It couldn't be automated. However, what they really meant was that it couldn't be fully automated. And what are engineers if not creative problem solvers?

[ A free guide from Red Hat: 5 steps to automate your business. ]

Conclusion

People tend to believe automation myths. It is important to understand that automation can be time-consuming, but it is likely that it will be of value to you and your team. There will be times when automation breaks and fixes need to be made, but it will pay for itself by saving time and reinforcing the benefits it provides.

Sometimes it is difficult to automate tasks, but take those challenges as an opportunity to innovate and share the knowledge you gain out of it. Lastly, it is very likely that when you do a certain task once, you will have to do it again, and if you automate it, you set yourself up for success.