Recently I've found myself having conversations about just when and why network engineers should be considering a mode of operation we'll describe as "Network Automation". Networking folks are investing huge amounts of their own time learning about Python, APIs, and network device programmability to query and configure their network devices. But why?
Organisations should be able to recognise real tangible benefits by automating repetition. By eliminating the manual daily, weekly, monthly tasks, benefits such as:
should be realised.
And yet so far, employers and businesses are not starting projects to deliver network automation projects in their droves. I think it's because "Network Automation" in itself doesn't show the benefits mentioned above.
What am I talking about? Let me explain.
The first part of the problem is how we define the term "Network Automation".
Very simply, this is usually taken to mean executing some kind of script that automagically completes configuration or information gathering tasks that a network analyst or engineer would typically run manually. The intention is to achieve an improvement in speed, accuracy and/or consistency. Typically, this will start with the network engineer building said tasks using a programming language or similar.
There may be a number of elements to those tasks that in turn require to be assembled into workflows using mutiple toolsets. She or he might gradually bring the scripts into service over time after iterative testing and debugging.
This results in a set of loosely connected tools to carry out those repetitive tasks. One or more of the tools may be Open Source. There may be a range of licensing and support arrangements, and interdependencies that need to be revisited each time one of the elements is updated. Code versions on managed devices may change and when they do, methods of access to the network devices may need to be modified.
All of these things will need to be managed by the network engineer who - unless they are appropriately trained - will not have the software development or application infrastructure skills to effectively carry out that role.
Note that this development and maintenance process is network-centric - it is all about achieving the goals of the network engineer as part of their role. So there is also a danger that "Network Automation" can be seen by some in an organisation as a benefit only to the engineer who develops the capability, to make their life simpler and to "look good on their resume".
That's not easy to answer without re-framing that question. What should we be aiming to achieve using these automation techniques? Why are we automating those tasks again? As we've already said, we are trying to make it better, easier to operate. But as we already know, networks are ever-more complex as we need to deliver progressively more capability to an increasing number and spread of endpoints.
In reality, it comes back to the fundamental question of what we are trying to achieve by having a network in the first place. Who does it serve? And why?
Today, the network is essential to all of our IT systems - and our IT systems are everywhere. Yes, we have computers that need to access applications, but we also need to collect data from an increasing array of devices and store it somewhere for analysis. We also need to be able to make things happen around our organisations and issue the instructions from a central command point. Hence we have connected CCTV, door entry systems, refrigerators, weighing scales, warehouse robots, paper mills, printing presses and conveyor belts.
The point is that all industry, all businesses, require these systems to be available at all times. And connectivity is the foundation on which all of those interactions are built.
The role of the network architects, designers, and engineers, is to ensure that networks are built that serve the purposes of the businesses who require them to operate these systems. They create networks from devices from different vendors using the appropriate technologies to ensure that the customer's connectivity requirements are fulfilled.
So the outcome we're looking for is to maximise application and data availability across our organisations. And that means that the purpose of any automation should be defined and measurable in terms of how it contributes to service availability.
I've talked about the ideas behind IBN in previous posts -notably https://ipfabric.io/blog/can-you-handle-the-truth/ and https://ipfabric.io/blog/declaration-of-intent/ - and this is a paradigm which certainly helps solve this conundrum. By adopting an IBN strategy, there is a defined path from business requirement to network configuration via the network designer creating automated workflows to deliver the business outcomes. There is also a part to play for Network Assurance - as the network must be measured to see how far it meets business intent. If it drifts from that intent, automated changes can be made to bring functionality in line with expectation.
The operational ecosystem around the network - monitoring and telemetry, change and incident management, compliance and lifecycle reporting - needs to be integrated and contribute to the overall "wellbeing" in a consistent manner. The network assurance platform has a part to play here too as it forms the definitive operational view of holistic network state: it is used to validate the information that is held in those operational platforms.
These are the principles on which IP Fabric has been built. Introducing IP Fabric to an existing network allows you to start on a path towards the IBN ideals by bringing automated network assurance to your network operations.
So what am I suggesting? Don't just think about automating your network config. Aim higher. Think about how you can automate your network operations to better fulfil the requirements that your business has for it. And understand how Intent-Based Networking sets out a framework for just that.