OK, so The Business has given us the nod to proceed, now the fun begins right? Fire up VS Code and lets get programming!!

Hold your horses! In the previous post, we considered the “Why” … we now need to consider the “How” before we just dive into the “What”!

No automation project worth doing will have a linear flow – do this task, then this task then this task, stop. Every operational activity we carry out in the network:

  • must be repeated across a range of elements
  • has dependencies on other tasks or data and
  • will be conditional on the existence of certain states of certain devices.

How do we know what data we need from which devices to make decisions? How do we know which elements need to be changed to add new capabilities to the network?

It’s vital to take a structured approach here so we know:

  • what elements are needed to be changed
  • where data comes from and goes to
  • where code is required
  • what changes in operational process are needed

And so on. We can save ourselves time and effort if we carefully consider the broader impact of the processes first.

I’ve pieced together a 5-step plan for tackling automation tasks that has served me well so far.

Write a problem statement

Define the nature and – most importantly – the scope of the issue you’re trying to address, considering the problems it solves. The process of working this out is extremely valuable – it helps identify the success criteria for the activity, and the amount of time required to deliver.

Map out current workflow and highlight weaknesses

Taking the problem as stated, start breaking it down into its constituent parts. Understand where elements of the process have pre-requisites, are dependent on external factors, or indeed on other parts of the process. Also consider where the process can go wrong, constraints and bottlenecks. And lastly, try to appreciate where it may be possible to extend its reach and provide data to other areas/systems.

Rearrange into target workflow

Now start to structure the target process using a flowchart or similar. The output here is referred to as pseudo-code – a high level representation of the process that takes the structure of a programme but can’t be executed yet as the lines in the pseudo code are descriptive only.

Look at regularly repeated sub-tasks, loops, conditional branches etc to develop the structure of the solution. And at this point, you will want to consider the tooling at your disposal as certain platforms may already incorporate a number of elements of your activity as atomic tasks.

For example, consider the case where you want to gather a piece of configuration data from every device in the network.

Using Python, you might have to write a programme which:

  • reads a list of devices from a file into a list,
  • loops through that list,
  • connects to the device
  • using the vendor-appropriate commands, retrieves the information
  • parses it and stores it.

In Ansible, the same loop is implied by providing an inventory of those devices. You simply write plays which retrieve and parse the information depending on vendor.

IP Fabric collects that information for you in each snapshot. If you have the platform available to you, you simply make an API request to IP Fabric. You no longer have to concern yourself with connecting to the device or knowing the vendor commands to retrieve or parse the info.

Iteratively refine the tasks

Taking each task and subtask, you break them down into the lower-level constructs, commands and variables. You are looking to have atomic actions defined for input/output of data and the actions on external devices and systems. The output from this phase is a low-level description of the actual system logic, practically down to code level. You are wanting to identify the functions, classes and algorithms required to deliver the output.

Code and test

Only once you have completed all of the previous steps are you really in a position to reach for your programming tools to get started! You now need to test and document your input/output mechanisms (including the API calls that may be required). You can now assemble logic from the pseudo-code, building re-usable classes and functions for repeated tasks. There are a load of programming Best Practices to follow here which are too numerous to cover in this post …

Where does IP Fabric come in?

Its said that as many as three quarters of all network automation tasks are concerned with iterating through the network, retrieving data, collating it and analysing it. This is no mean feat especially in today’s complex multi-vendor, multi-domain environments . There’s a lot of work to do there just to get a consistent view of that data across the network.

Luckily for us, IP Fabric already does a huge amount of that for you. If you’ve seen its discovery in action, you will know that it will take away a lot of the ‘grunt’ work. The system gives you access to the information you need through simple API calls into the platform’s database. Then you can concentrate on how to use that information to enrich your network operations experience.

If you have found this article helpful, please follow our company’s LinkedIn or Blog, where more content will be emerging. If you would like to test our solution to see for yourself how IP Fabric can help you manage your network more effectively, please contact us through www.ipfabric.io.