The Three Faces of IT
The “IT” function has been alive and well for over more than half a century. In fact, if you trace Information Technologies all the way back to the earliest IBM...
December 11, 2018
People say they want automation in the same way I’d recommend improving your ‘language-ing’ if you’re traveling to a foreign country. It’s not a very precise description of what you need to do, and you might not apply the appropriate things to be successful.
Network Automation seems to be in an odd place these days. Sure, it’s desirable, and not many network engineers would go out of their way to preserve the busywork of CLI crawls, compliance audits, or other time sinks that accompany a complex network, but automation keeps getting shot down where it should be embraced.
One of the more prevalent problems in tech today is concept dilution. When companies realize there’s a craze for a new feature or ideology, there’s a rush to be in on that feature. Take cloud for example – once this methodology was sufficiently accepted by the public, an epidemic of product releases followed that supposedly had cloud implications. The same thing happened with SDN, once that became popular too. When enough people jump on a bandwagon, the original concept gets diluted and people can’t agree on what it means anymore
Similarly, many companies want to sell Network Automation, but there must be a way to precisely discuss what a tool does before it can be considered a solution to any problem. The alternative frustrates clients with products that promise one thing and deliver another
This need for clarity is the force driving this blog post today, as I’m going to break down Network Automation into three distinct categories.
Each of these three topics is technically Network Automation, but each one fulfills different use cases within the greater scope of the network. You might need one, you might need all three, but just as it’s essential to know what illness you have before taking an antibiotic, you should probably have the problem these tools solve before you go out and buy one.
Let’s dive in!
Change management is the ability for a network operator to remotely touch a device (or multiple devices) in order to backup or push config file changes. The content of these changes can be full configuration rewrites, such as pushing a golden configuration file onto a set of devices, or just basic things like policy removal, VLAN additions, OS updates, etc.
Companies that provide NCCM are enabling Network Operators to automate the ability to implement network changes of any complexity on a massive scale. This is a huge step up from how things used to be. Personally, back when I was a Network Engineer, I had to allow a pretty significant time frame for a large network maintenance window – every device presented an equally large set of checks and functionalities I had to manually validate.
It’s a rather simple set of features that make up the essence of NCCM, and as you’ll soon see these attributes remain mostly separate from the other expressions of Network Automation.
Major NCCM tools/vendors include:
SDN has enjoyed a very swift transformation from a curiosity to the hot and must-have data center solution. SDN is a response to the limitations of traditional networks – the ones that frequently buckle under the pressure of more users and applications consume cloud and internet to greater effect.
As automation, SDN is focused on centralized device management and programmable network provisioning.
You might see the overlap with NCCM in the ability for SDN to orchestrate network functions, but the difference here is that instead of replacing individual lines in a configuration file, here a network device’s basic operations are managed by a single software application. NCCM is distinct from SDN, as in an SDN environment devices are no longer considered independent, but are part of a greater centrally managed system.
SDN provides enhanced scalability and agility to clients – respectively, the ability to expand their infrastructure without increasing CAPEX (capital expenditure – like buying new hardware) costs and their ability to increase the output of services without incurring increased OPEX (operational expenditure – like keeping the lights on) costs similarly.
Where an engineer was once purchasing and requesting new devices, they can now simply provision resources from a piece of vendor-neutral hardware and execute their virtualized network function on top of it with code.
There is certainly much more to SDN, but its essence can be distilled into these two functions (Centralized Management + Provisioning) listed above. If you’d like to know more, be sure to check out my White Paper The ABCs of SDN, which breaks down the methodology into even more granular descriptions.
Major SDN solutions include
Now, we arrive at the final category of Network Automation, which we at NetBrain refer to as Automated Network Operations. This style of automation covers a wide array of use cases, ranging from troubleshooting, network security, compliance, and even documentation. This is, in most respects, the widest and most diverse field of Network Automation, but they’re pulled together here for a specific reason – the majority of these use cases stem from the mass automation of CLI parsing and visualization in terms of data retrieval and data analysis.
This includes troubleshooting because Automated NetOps will enable you to reduce the overhead involved in searching through devices and collecting relevant routing and interface information. Imagine trying to troubleshoot slowness between a web server and database:
The same principle of enhanced data collection can also be applied to Network Security and Compliance as well:
This also includes documentation; sure, a good platform would allow you to pre-record workflows and execute them on the network, but a great NetOps Automator is going to record which actions were executed in your environment and list them for you once your workflow is complete. A great NetOps Automator would also trivialize the creation of documentation.
As you can see, these use cases are rather removed from Change Management and SDN, as they’re focused on quickly performing what an engineer would normally be responsible for.
Bonafide NetOps Automation tools are hard to come by. Orchestrating a solution with minimal human intervention requires a degree of programming, and is difficult to scale up with organizational growth and complexity.
NetBrain, however, provides the clear standout in this category: its massive library of built-in CLI parsers and network features like Comparison, Dynamic Mapping, A-B Path, Runbook Automation and more enable the user to automate the day-to-day operations that consume most of their time.
At the end of the day, Network Automation is not just a desirable goal anymore, it’s becoming a necessity for organizations to keep up with their business growth. The network is all too frequently a choke point, and as a result, people are going to seek out automation tools to fit their needs.
As this article comes to a close, let’s briefly recap:
Now, these aren’t the only use cases for the three faces of Network Automation.
Hopefully, this thought perspective has provided you with a clearer understanding of the tools you can empower yourself with.