Before beginning a network automation project, you need to wrap your head around what tasks are involved and what it means for your organization as well as your network admin staff. Simply put, a mental shift is required when you decide to not be a network dinosaur and to successfully adopt automation. The shift must occur for both employees and management. It is going to take time to learn about new tools, how to apply those tools, and how to change processes to incorporate the new technology into the network's operation.
You must spend time to learn new things. Think of the time when you first started to learn any complex new technology (OSPF, BGP, or MPLS, for example). Remember how foreign it was in the beginning? How long did it take to become comfortable with it? How long did it take to get conversant in it? (I define "conversant" here to be knowledgeable enough to carry on a conversation about the technology, understand its strengths and weaknesses, and knowing how to best apply it in the real world.) Attaining certifications took comparable amounts of time, study, and experience to gain a sufficient level of understanding. You should expect to spend a comparable effort to learn about network automation.
Network engineers will need to know the details of how the network automation works in order to perform troubleshooting when things don't work as planned. I think of the change as adding another level of interface on top of what we already know. The Web developer part of the IT organization already has a name for this depth of understanding -- full-stack Web developer. This is someone who is capable of working on the full stack of a Web application, from the front-end (Web user interface) to the back-end (authentication, application processing, and database) parts of an application.
[Note: Is there a similar name for network engineers who understand the full stack of network automation, from programming to APIs to the underlying device configurations? Perhaps "Full-Stack Network Automation Engineer?" Or is there a better name? Leave a comment if you have a suggestion.]
Getting Started
Python has become the most common network automation language, so I recommend learning it. There are several Python tutorials on the net as well as a lot of YouTube videos. You'll need to start with the language syntax, which relies on indentation to separate statements. First, find an editor you like that can display Python in color, which helps you identify indentation mistakes (many people like Sublime Text). Then tackle looping and control flow statements. Next, you'll need to understand how to create data structures using tuples, lists, and dictionaries, then advance your understanding with lists of lists and lists of dictionaries. You should learn how to represent network configuration parameters in a single data structure. You'll be comfortable with the language when you have moved from basic interface configuration parameters to BGP or QoS configuration parameters.
The next step is to learn how REST interfaces work. You'll find that PostMan is a useful tool for playing with APIs. It may take some time to understand the links between different elements of an API, and PostMan helps you understand the details. For example, when you create a session, the API may return a session ID that's a long hexadecimal string. This session ID is then used on successive API calls. You'll see similar IDs used for a variety of things in the APIs, so become accustomed to using them. It shouldn't take you too long with PostMan before you tire of cut-n-paste with its manual interface. Now you're ready to start using a programming interface with those APIs.
This is the point at which you should look for your vendor's education offerings. Virtual labs and free online training courses are becoming common. Some courses will also help get you up to speed on the languages as well as the vendor-specific APIs.
An alternative to vendor-specific education is to learn a vendor-independent automation system like Ansible or SaltStack. You should also learn a templating tool like Jinja2. There are free tutorials, YouTube videos, and for-pay courses, so there should be something that fits your learning style and financial situation. I took a for-pay course that included guest speakers who described how they used automation. I found their examples to be one of the most valuable parts of the entire course, because it showed me what was possible. For example, one person was able to reduce a set of multiple BGP peering configurations to a much smaller data structure. Another example was the small set of configuration parameters that were needed to configure a complete leaf-spine data center pod. I also liked the idea of creating a list of infrastructure interfaces that should be connected (i.e. network device connected to another network device) and using automation to verify that the desired connectivity was accomplished.
It's a Journey
Adapting to the new world of network automation is a journey. Think of it as evolution of the network engineer. You either adapt or you retire. Unfortunately, there are no short-cuts. The lessons to be learned provide the experience and understanding that are needed to properly do the job. If you're good at your job (whatever it is), you develop a "gut feel" for good designs, good implementations, and good operational characteristics. (This applies to non-technical jobs as well.) With this kind of intuition about your industry, you sometimes need to stop for a few minutes to determine why your intuition told you that something wasn't good. This kind of in-depth understanding of a system only comes through a lot of experience. This level of experience comes from making a lot of mistakes, understanding why they occurred, how to fix them, and how to avoid them in the future.
A colleague of mine, Carole Warner Reece, recently described her start on the path of network automation. She really started over a year ago at the 2016 CiscoLive conference, where we attended a Cisco all-day class on basic automation. The material was presented quickly and we had to work quickly. Some of it didn't "stick" in our heads until we went back over it. I share this to emphasize that network automation is that kind of journey, so be prepared for a few bumps along the way.
