Don't Let the Automation Snowflakes Stop You
You know that time of year when snowflakes mean more than description of uniqueness of your networking infrastructure? Some people love to complain about that season and how the weather hinders them, others put on sturdy winter boots and down jackets, change tires on their car, and have tons of fun.
Network automation is no different. Sometimes you can persuade your peers that it makes sense to simplify and standardize the infrastructure to make it easier to abstract and automate (consider that an equivalent of going to a tropic island with shiny beaches and everlasting summer), other times you have to take out your winter boots and make the best out of what you got.
Some people have a hard time with that. Here’s what an anonymous commenter wrote on my No Prior Scripting Knowledge Required blog post:
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.
Assuming you can’t get rid of any of the current complexity and uniqueness, there’s still tons of things you can do:
- Use automation to extract data from the network and create reports you couldn’t get from your network management system. Some people collect MAC and ARP tables to be able to track the hosts… add time-series database to that and you have a complete history of changes in your virtualized environment. Others extract optical transceiver levels from diagnostic printouts to detect failings cables, or draw diagrams of multicast distribution trees. The opportunities are limitless;
- Manage configuration inconsistencies - use automation to make sure at least common parts of device configurations don’t diverge too much. It could be as easy as ensuring all devices have the same admin users and timezone configured.
- Keep a track of configuration changes and manage device configurations like you would manage any other code - also known as GitOps.
We cover all these scenarios and many others in the Building Network Automation Solutions online course. Don’t feel ready to join the course? The Ansible for Networking Engineers webinar that’s part of Standard ipSpace.net subscription will get you started… but you’ll miss the bigger picture and breadth of tools covered in the automation course.
You do not have to tell him "please use the automation" because you should do it.
Whenever I was involved in really difficult problem with distributed system (complex network) the python programming to collect data in the right moment was a must.
No alternative than automation.
So I think you cannot make someone to use automation because automation is good. I think it should be driven by real needs (economic, complex problem to handle, etc)
https://github.com/YangModels/yang/tree/master/vendor/cisco/xe
Ref.:
https://blogs.cisco.com/enterprise/networking-apis-the-new-currency-of-networking
1)
Learning Module, “Home Lab: Setting up Your Desktop OS for Network Programmability”
https://blogs.cisco.com/developer/new-devnet-learning-module-home-lab-setting-up-your-desktop-os-for-network-programmability
2)
Firepower Programmable APIs for Developers. Learn about them
https://blogs.cisco.com/developer/firepower-programmable-apis-for-developers-learn-about-them-at-cisco-live-barcelona