No Scripting Required to Start Your Automation Journey

The “everyone should be a programmer” crowd did a really good job of scaring network engineers (congratulations, just what we need!). Here’s a typical question I’m getting:

Do I need to be good in scripting to attend your automation course.

TL&DR: Absolutely not.

I know that many networking engineers have no prior programming experience, so we start from scratch, use the simplest tool possible (Ansible), and you can go through the whole course without ever touching Python… although you’ll pretty quickly hit limits of what you can do with Ansible without custom Python filters or modules.

When you hit those limits you have two options:

  • Learn some programming or
  • Find someone else to do that part of the job.

As I usually explain during the course introduction, you probably invested years into understanding networking and becoming a good networking engineer. Use that knowledge in a new domain (because after all, we’re talking about network automation) instead of trying to compete with high school kids.

After all, unless you want to be a lone consultant, you probably work in a team - and as our ancestors discovered when they first formed hunting teams, division of work and competences (while at the same time keeping in touch with what other people are doing) usually gets you better results than if everyone tries to be jack-of-all-trades (and master of none).

16 comments:

  1. I am a part of the team doing network / system automation for more than 10years. The team (about 30 people) are split into network engineers (responsible for the PoC + configuration templates) and regular developers )responsible for the GUI (to enter customer specific data and visualize the system), data models, etc).
    ---
    When we add new feature to the network/system both sub-teams agree on the data model and the work is split - app guys work on the app whereas the network guys spend substantial amount of time on PoC. This involves building lab, testing and submitting issues to the vendor, etc. Once they are done they prepare configuration templates and those templates are integrated with the app.

    What I want to say:
    1. In this project the automation is seems as regular (nothing-fancy) work
    2. The network engineers do the same work as they did in the past - the vendor sw is buggy - do not expect miracles through the automation. You still need to do PoC and try to reproduce issues. The only new skills required for the network engineer is to understand the data model + basic template scripting.
    4. The deployment of configuration files is handled by the GUI app. The GUI app also visualizes the system, and allows to select system option, collects the Customer specific data and crunches all the data with configuration templates according to the data model. So in this particular case there is nothing wrong to have GUI app.
    6. The huge part of the work is related to testing of what the app is supposed to generate (the actual configuration files). Again, testing consumes huge amount resources.
    ---
    We started doing automation before the automation religion started - we weren't religious - it's a 'must have' since the product beginning because thanks to the automation we can reduce the *perceived* system complexity.
    The user does not see boxes - it sees the sub-systems (and select one of the gazillion system options including legacy stuff) at least one level higher than what the network engineer sees.
    The whole product is rather big - up to thousands configuration files are produced in the consistent way.
  2. We're still struggling at the "simplify phase". Once we're past that we go to the "standardize phase" (hopefully within the next 10 years). So no automation/programming at the moment.
    Replies
    1. Yes, our case is different. We fight complexity of the huge complex system with PREDEFINED options. So the automation makes perfect sens from this point of view - really saves money and helps avoids errors.

      I have never worked in the pure IT dep. so I do not understand what REAL issues are solved by the automations in such places.
      Maybe someone having real life experience could describe the benefits, especially when "standardize phase" was NOT achieved.
    2. According to what Ivan taught us, it makes sense to go through the following stages: simplify->standardize->abstract->automate. If you don't follow that path you would have a system full of exceptions and only a few similarties which makes it kinda hard to automate (no cookie cutter).
    3. Yes, perfectly understand. I have always believed that the automation existed in the past where it made economic sense (my example).
      So it is interesting (to re-phrase my last question) how does the automation work in real life IT dep where "to simplify" task might be challenging (many exceptions, legacy support, etc).
    4. @Anonymous: while what you summarized is the optimal way to go, don't allow the snowflakes to stop you - there's always something you can make better even in a typical overly-complex enterprise environment... it's just that you won't be able to reach the holy grail of full-abstracted automated self-provisioned services until you manage to persuade everyone else it's worth cleaning up the Augean stables.
    5. @Gogus:

      > how does the automation work in real life IT dep where "to simplify" task might be challenging (many exceptions, legacy support, etc).

      One small step at a time. :-)

      First, if you have 100 switches, do you really have 100 different brands and models, or do you perhaps just have five brands and ten models?

      Start then with the brand/model that you think will be the most common/important for you going forward. Identify fragments of commonality. E.g, all switches should do syslogging to $LOGSERVER, fetch time using SNTP from $NTPSERVER, and have SNMP set up to allow read using community "public", and no write access over SNMP.

      Then write automation modules to make sure those things are what they are supposed to be. Even just having scripts to *check* that things are correct (and just complain if they are not) can be a big help.

      You also need to nudge, cajole, bully and/or force commonality going forward. This is a multi-year project... Make sure that your users and management knows the costs of not being unique.

      Identify unnecessary differences. Do you have the same linecards in the same slots in your core routers/switches, or is a certain card in slot 1 in one router and in slot 3 in the other? Is distribution switch X connected to port 17 in one core router and port 23 in the other? Do you have the same VLANs/VRFs on all the uplinks from switch Y?
    6. We achieved 100% system automation. We cover many vendors and all legacy devices.
      Ao I know how difficult is achieve this level of automation.

      This consumes huge budget. And needs good Business Case -at least be ready to answer the question "what IF we do not automate the network";)
  3. Ivan, I have been through your courses, but, I feel like I need a revised/updated version with a little more hand holding. I have been spoiled by CBT Nuggets and INE.com with much more hand-holding through new technologies. I learned a ton about Ansible from your courses, but, I continue to struggle to implement even some of the basic stuff in production. Unfortunately I deal with way too many snowflake type situations.
    Replies
    1. I always love to hear how I could improve the courses - sent you an email, appreciating any feedback you could give me.

      As for the struggle - I never said automation would be easy (contrary to what some evangelists would love you to believe), but it's definitely reachable, as proven by hundreds of your peers. It just takes a lot of effort to do anything worth doing (or everyone else would already be doing it).
    2. Ivan, your diligence with requesting feedback is awesome! Here are some of my suggestions based on what I am used to with other vendors like INE.com, CBT Nuggets, GNS3 Academy, Linux Academy, etc.
      - Start from scratch, assuming a typical Windows user, installing a Linux/Ubuntu VM (via Virtual Box or VMware Player) to get started
      - Stick to the same version of Ansible for all the demos and examples
      - Stick to JUST Ansible - no GitHub, Vagrant, Docker or even Python - all of which come with their own significant learning curves
      - Have separate dedicated advanced chapters much later in the course for "Ansible with GitHub" and "Ansible with Vagrant" and "Ansible with Napalm", etc.
      - Encourage and assume that the audience is going through the same examples as you with you - so "Let's do this script together and see what happens"...

      If you can make something like David Bombal's "Ansible for Network Engineers: Quick Start GNS3 & Ansible" course, but also go through all the same advanced stuff you go through with same kind of examples, that would be my ideal Ansible course.

      You courses still did a million things right - like doing an amazing job of explaining the theories and having lots of examples. They were still very much worth the time and money in investment and I still to recommend them to others. Above are recommendations to take your Ansible offering to the next level :)

      Thanks.
    3. Hi Salman,

      Thanks for the feedback. Most of the things you mentioned have been solved for a long long time:

      * There's an "official" install script I recommend everyone not familiar with Linux uses to set up Ansible environment. The script is also on Github, and has been recently updated to Ubuntu 18.04.
      * There's a separate "Ansible for Networking Engineers" course that focuses just on Ansible, and it's part of the network automation course... so there's nothing stopping you from focusing on Ansible first. It's just that I believe network automation is much more than just Ansible, and that people serious about doing network automation should realize that from day one. It's way too easy to hack together a few scripts in Ansible, call it a day, and become Expert Beginner.
      * "Ansible with NAPALM" is a separate section, as is "network state validation with NAPALM"
      * There's no "Ansible with Git" ;) You either use Git or you don't. However, we do have a "Getting started with Git" and even a chapter on GitOps for people who'd like to do that with Ansible.

      So I guess we're almost there.

      Finally, while I'd love to have "everything on a single version of Ansible" experience, that will become possible when the developers calm down and stabilize the feature set. However, they do a great job keeping the older stuff working, so (as I replied to our grumpy Anonymous friend) most everything I ever created still works.
  4. A lot of his Ansible material is outdated and doesn't work anymore. This has to do with the rapid development of Ansible. An update of the videos + GitHub repo is much needed.
    Replies
    1. I agree with you - Ansible is rapidly changing, but instead of jumping at every new fad, it's better to wait for things to shake out. There's a reason they mark some modules "preview", and I try to follow that same mentality and tell my students how to create solutions that are robust, stable, and deployable today. That unfortunately sometimes includes not using the latest features (and it's not just Ansible, I do the same with any network technology I cover). I know that some people have a problem with that approach, but many others appreciate it.

      As for "doesn't work anymore" - I was digging through the network_cli and network modules code this week updating the "Executing commands on network devices" material, and was pleasantly surprised to see all networking modules still support LOCAL connection and PROVIDER parameter (which is even abstracted into common library) - Ansible networking team did a great job maintaining a stable interface. Having said that, while most of the examples should still work, there might be things that got broken, so please feel free to submit a GitHub issue.

      Finally, there's a reason I put all my examples on GitHub instead of making them part of paid course material - it's called "community". I wanted them to be useful to networking engineers who won't or can't join the course, and you're most welcome to submit a Pull Request any time you find something you think should be fixed. Not only would that move you out of disgruntled anonymity, I love to write blog posts about people who do great stuff.
  5. Hi ivan

    Can you post the link of github where i can import to my directory. Do u have document which enlists the steps that is required to do it.
Add comment
Sidebar