When I talk with Network Engineers and Operations teams about automation, often times the response is: "I am not a programmer, so I can't do this". Worse yet are folks in the blog-o-sphere saying that if networking folks don't become a programmers, they will become obsolete. This is all rubbish.
Have you ever used Linux, and hacked out a shell "for" or "while" loop to do a quick repetitive task? I'm sure you have, but would you call that programming? No, of course not. I have friends that are in different fields, like science and finance. They use programming languages, like Python, to do numerical analysis, as a power-tool for their job. If you ask my friend the scientist if they are a "Programmer", they would say "NO! I am a Scientist!"
So there seems to be a (self inflicted) distinction between using a programming language as a power-tool and being a programmer as a profession. And yes, I do believe there is a distinct difference, and no, it does not mean you have a Computer Science degree.
So perhaps we can all agree that using a programming language does not make you a programmer. It's just a power-tool to help you do you job. So now you can get over it, and start to have some fun and be more productive.
AUTOMATION IS ABOUT CONSUMPTION
My basic thesis is that automation is defined by the nature of the consumer, that is, the person using the automation technology. The technology could be a purpose built tool/product, an IT framework, a set of language libraries, SDKs, or a combination of the above. I've even tried to make this concept consumable by creating an analogy to "ice cream" - as described in this blog.
If we treat automation as consumption, then we must consider the "digestion factor", or "how easy" can we make automation consumable by the user, you, the non-programmer. If you are presented with an automation task that is "too hard" then it is not consumable, and thus creates "indigestion". For example, let's say that in order to do some automation task you had to develop in Java and write over 500 lines of code. #fail.
My rule of thumb: Do something useful in less than 50 lines of code, or just do it interactively.
THE "JUNOS EZ" LIBRARY FOR PYTHON
The "Junos EZ" library is a way for non-programmers to start benefiting from using automation without requiring them to be hardcore programmers. It is not a set of APIs - APIs are for application programmers - which we've already agreed we are not. Can Junos EZ be used by "programmers" to build tools? -- of course. This library could also be the basis of integration with other higher-order IT frameworks (like Ansible or Salt).
This series of blogs "Python for Non-Programmers" will introduce the major concepts of Junos EZ. These include:
Once everything is installed, you can do a quick check by connecting to a Junos device, and displaying the "facts" like software-version and serial-number. I've documented this example, and others, on a previous blog here.
AUTOMATION IS A JOURNEY, AND SO IT BEGINS ...
You now have an environment and the consumable tools to begin automation efforts. I would suggest by starting with "read-only" automation, like gathering statistical information or correlating information like the SRX example.