Some Operations Are Not Worth Automating

Ish wrote an interesting comment on my Network Automation Expert Beginners blog post. He started with:

[Our network has] about 40 sites, but we don’t do total refresh cycles in bulk, just as needed. Everything we do is sporadic, and I’m trying to see the ROI on learning automation for things that are done once in a while that don’t take much time to do manually anyway.

There are two aspects to this part of his comment:

  • Is it worth automating sporadic operations?
  • Is it worth learning about network automation?

The latter is easier to answer: if you care about your career growth, you should learn the basics of network automation. Like public clouds, automation is becoming a must-be-aware-of tool, and not having a clue about it might severely limit your job-hunting opportunities. Do yourself a favor, figure out what it’s all about, and make sure you won’t stop at the Expert Beginner “writing Ansible playbooks or Python scripts” phase. Do I have to mention that you’ll find plenty of relevant webinars and an online course on

Now for the more ambiguous part: automating sporadic operations. You should always ask yourself, “how sporadic are they?” For example: with 40 sites, I’d expect one refresh every month or so. Is that worth automating? Developing a full-blown solution that would roll out a new location on its own doesn’t make sense, but having consistent configurations on all sites might be worthwhile. That brings us to another question: assuming device configurations change to fix omissions or introduce new functionality, how do you ensure consistent device configurations on all sites? Who enforces that, and how?

The next usual objection is time spent automating things. Back to my reader:

I can spend 40 hours trying to figure out how to automate something that will only take me 30 minutes and that I will only do ten times a year. Only for nobody to use that same automation method, or for it to become obsolete, or simply need to spend more hours maintaining and updating it.

Trying to evaluate the benefits of automating an operation based on time saved worked great for Henry Ford, but it’s the wrong approach in most network automation environments. You should ask yourself:

  • How much will we gain from having consistent deployments?
  • Will we reduce troubleshooting efforts because we won’t have bespoke configurations on every device in the network?
  • How much simpler will it be to troubleshoot the network at odd hours, knowing it’s configured consistently?
  • Will we increase speed-of-deployment because we won’t have to go through numerous “this doesn’t work (again), fix it” cycles?

Also, stop focusing on configuration deployment. Network automation is much more than that, even though the preachers of the “take a pinch of YAML, add a sprinkle of Jinja2, and shake well in Ansible shaker” gospel usually fail to mention it. There must be some repetitive operation that drives you crazy. Automate that! Nothing along those lines? You must be incredibly fortunate, but here’s another idea: do you have a repository of device configurations? Is it under version control? Can you figure out who made any particular change on a device you’re troubleshooting and why? Do you think that having that information would make your life easier? Oxidized might be just what you’re looking for. For more ideas, browse the sample network automation solutions created by the attendees of network automation online course.

Finally, it’s perfectly fine if your network doesn’t need automation. I just hope you came to that conclusion after realizing the full potential of network automation and making a well-informed decision. 400 automation-related blog posts, a half-dozen webinars, and an online course might help you get the prerequisite knowledge.


  1. "I can spend 40 hours trying to figure out how to automate something that will only take me 30 minutes and that I will only do ten times a year."

    Which is 40 hours spent learning something new and useful vs. 6 hours of toil that won't go away.

    1. For some people, that toil equals job security and there's no motivation to get better at what they do or push their profession forward. I'm thankful that humanity as a whole doesn't think this way or we'd still be living like our animal ancestors.

      Automation is all about using and building better tools to improve your workflows and their outcomes. Sometimes you get to use what others built, but the scary* part in the open source world is you actually have the freedom to use your own imagination: you can** build something that solves 100% of your use cases instead of hoping a random commercial tool appears that covers maybe half of what you need (and tells you what you should be doing instead of the other way around).

      • See previous paragraph. **Nothing worthwhile doing is always easy or obvious, and you might need help (e.g. see all of Ivan's suggestions for broadening your horizon).
Add comment