Simplifying Network Complexity with Interactive Automation

by Sep 10, 2019

Ed. note: The following transcript has been drawn from the on-demand recording — no registration needed or form to fill out — of  NetBrain’s Just in Time Automation for IT Operations webinar. Jason Baudreau, NetBrain VP of NetBrain, is your host. 

Speaking of know-how . . . it’s no wonder subject matter expertise in networking is so hard to come by. Networks have become incredibly complex over the last five or ten years. I see three examples which validate this.

1. First is the trend toward SDN and SD-WAN. This is bringing a massive learning curve to the network management teams. What I found is a reported 57% of organizations looking to adopt SDN by next year. This change is coming whether we’re ready or not
2. And then there’s the skill set to manage the disparate vendors. There are over 100 network vendors. An enterprise network will typically leverage between, say 6 and 12 of them — different vendors for routing, switching, security, load balancing, etc. — each vendor coming with its own CLI context, its own learning curve, etc. You don’t need to look any further than Cisco’s certification track to see what I mean.
3. It used to be that a network could be managed end to end by one general engineer. Now expertise is required across data center, across campus, for voice and video, and so on. Last month at Cisco Live, Chuck Robbins was talking about adding to the certification track for more DevOps, for more programming and automation skill sets as well. So when issues occur, different skill sets are required to help identify the source of the problem.

Codify tribal knowledge

Making more senior-level know-how accessible to that first-response engineer leaves more time for those senior engineers to take on more strategic projects that are falling by the wayside. If this is done well, it can also mitigate the risk of engineers leaving an organization and taking all their knowledge with them.

In order for senior engineers to do this, however, it has to be incredibly easy — because adding more overhead to a senior engineer’s workload is just not going to get this done. Otherwise, it’s just a good idea in theory but it’s never going to be executed well. So this process of documenting and sharing know-how has to be near-automatic.

Senior engineers can use NetBrain automation to codify their knowledge into what we call Executable Runbooks. They don’t need to know scripting to create this automation; it can happen almost automatically. It can be written once and executed anywhere across the network. So instead of manually documenting their subject matter expertise into playbooks or wikis, their workflows can be documented automatically as they’re troubleshooting in NetBrain. And these resulting Executable Runbooks can then be run by any engineer across any part of the network.

Adapt to the tools you’re using

Then there’s a different kind of expertise — the expertise required to operate different IT and NMS tools, like monitoring or packet inspection tools, for example. It’s like this meme about a NOC guy with a conveyor belt of tools. . . . Each tool on that conveyor belt is basically what I call a “data island.” That valuable data may be hard to access if different team members don’t have the access or the skill set required to use teach tool.

We at NetBrain looked at this challenge and thought about that old promise about a “single pane of glass” which the industry has been promising for years, this single pane of glass. We think that a network map is the right context for that proverbial “single pane” and that data from third-party tools — any data you’re looking for — can be visualized in the context of the map. This might be at a device or interface level. So we made it possible to integrate your existing monitoring, security, or ITSM solutions (anything that has API interface) into NetBrain, to bring the valuable data to one place. The goal is to make more effective use of your existing IT solutions, making them accessible to anyone you want to have access to those tools — and most importantly, the data within those tools.