Day 1 – Part 1: Context and Culture
Previous Posts:
Introduction: Free NSO Training Material for Enterprises (By Cisco IT)
Introduction
Before jumping into the details of NSO and how to use it, it is helpful to step back and look at what is meant by automation in general. Also it is very important to see NSO and automation as not merely a technological shift in tools, but also a cultural shift in thinking about problem solving and troubleshooting processes.
Lifting and shifting your existing architectures, business processes and people into NSO or any automation platform is a recipe for headache and inefficiency. What is outlined in this post is not meant to be the end of the discussion regarding this shift, but rather to start the discussion and provide some contextual clues so that you can be asking the right questions.
Context
The slide below (credit to Brandon Black for creating it) is a helpful visualization of three ways of categorizing automation efforts: Ad-hoc / Scripting, Re-usable Frameworks and Orchestration.
Some quick examples, in case the slide is not clear for each category are:
- Ad-hoc scripting: a standalone python file, or series of files which has statically defined inputs and outputs, often has passwords and commands statically defined for a specific use case. Common libraries used: Paramiko, Netmiko, pexpect.
- Re-usable frameworks: something along the lines of “insert your code here” or abstracting the complexity of coding, but still requiring moderate development work. Examples: Ansible, Ansible Tower/AWX, Django, company specific code standards.
- Orchestration: An application on a server maintains the state of the network and users use the platform to enact desired outcomes. Examples: NSO, ACI, DNA-C/APIC-EM
What we are saying here is that every effort to automate the network can be categorized into one of these categories. There may be exceptions or other categories that come up over time, but this is our humble effort to try and provide some nomenclature around categorically different ways of automating the network.
First off, there is a place for all three types of automation. This is not to say all automation needs to be orchestration, and none should be ad-hoc scripting. This is more to say that the maturity of a given automation can be evaluated by:
- How adaptable the automation is to varying inputs and output.
- How easy the code is to maintain and change.
- How easy the automation is to integrate into other platforms
- How much work is needed if any change to the use case is needed
- The level of detail needed to specify an intended outcome (intent based networking)
Feel free to chime in the comments if you have any other criteria you have found useful in differentiating between types of automation! (I know these examples are focusing on configuration compliance rather than real-time monitoring and other operationally needed functions)
One last thing to note is that NSO enables all three categories of automation. Obviously NSO is a powerful and robust multi-vendor orchestrator (hence the “O” in NSO). However, NSO provides out of box functionality to make scripting easier. Users can create standalone python, Java or REST based apps which read and write to the NSO APIs, making transactional changes to any piece of the configuration NSO has stored. NSO also provides bash commands which auto-generate package skeletons, making developing relatively trivial.
By using NSO for ad-hoc scripts, it also bakes in the ability to rollback and keep track of changes since all API calls to NSO are logged in the rollback log.
Culture
In an enterprise context sometimes moving toward an automation platform for end-to-end configuration management can be a cultural and mind-set shifting issue as much as it is a technological one. It will take time to convince key business and technical decision makers of the value of moving to something like NSO.
Here are some common objections we have heard from engineers when asked to learn NSO or automation skills in general:
- I am too busy to automate, or learn/practice automation skills
- I do not know where to start
- I get stuck setting up my environment
- I get interrupted when I finally get time to try
- I don’t see how I can automate this task, it is just easier to do it manually, since I know that will work
- There seems to be too many competing platforms (ansible, NSO, python, etc.), I don’t know which one to use
- I know how to use bash/SNMP/python/perl scripts, I don’t need anything more complex
Most of these are valid concerns. One big thing for engineers to think about is that the skillset of a network engineer is changing. Cisco (along with most vendors) are moving to software-defined everything. This is not to say there is no place for the CLI or traditional certifications are less valuable.
Rather it is to say that the coming years will include an expectation that engineers understand programmability at a basic to intermediate level in order to fully unlock the cool and new features on network devices. Routing and switching is still critical information, but being able to create a predictable, uniform and scalable network is quickly becoming an industry expectation, just as compute has done ten years ago.
In contrast to the previous objections, here are some guiding statements that we found helpful as we have undergone this journey:
- Carve out time in your week where you can learn and practice the skills without interruption (no cell phone, no jabber/spark/email, etc.)
- Have a humble and teachable attitude, being patient while adjusting to the learning curve
- Teach others what you are learning to reinforce the concepts
- Pick a very small task to start with
- Read lots of examples and follow the logic
- Consider not only the problem at hand, but the business process around it
- Don’t be afraid to ask others for help if you get stuck
- Use version control (git) and do not hard code passwords in code
- Actively seek to apply your skills to your daily job
- Write code / templates with readability and reusability in mind
Feel free to chime in with your own tips as well!
1 Comment