I think it’s safe to say network automation is pretty mainstream now. Judging by what vendors are doing and what the community is talking about, automation is more than the latest advent of hipster networking. It’s becoming the primary way many network admins manage their networks.
But there are a couple barriers to taking the leap into automation. For some it’s the steep learning curve. There are courses to take, programming languages to learn, and entirely new processes to get comfortable with.
But I’ve worked with enough network engineers over the years to say that a steep learning curve is not an insurmountable problem. Many engineers I’ve worked with have an eagerness to learn new things and grow in their profession.
I don’t believe the issue is learning how to automate a network. I think the real barriers are the time and resources it takes to automate a network at scale in a meaningful way.
Even in modest-sized networks, automation beyond a little screen-scraping for information gathering can get hard quickly. Think about a network with multiple overlays and platforms from several different vendors. All of the scripts, playbooks, and templates, will need to be written to accommodate variations in syntax, which, as any veteran engineer knows, changes as new code versions come out. And then they need to be properly maintained as the network changes.
This isn’t a problem for a skilled developer, but generally speaking, typical network engineers have minimal programming background and little time to build a bunch of scripts, delivery workflows, and new CAB documentation.
Simple scripts turn into complex scripts when configuration gets more complex. Network overlays, multiple platforms, changing business requirements, and frequent vendor code updates means maintaining those homegrown scripts is just as important as creating them in the first place.
I really believe the industry gets it – network automation makes sense, and so networking is changing. But how can an engineer in the trenches fixing routing problems, spinning up new sites, fighting with ISPs, and learning the latest licensing models actually get there?
Get Your Network Under Control
Gluware helps engineers move away from homegrown automation. With Gluware, an engineer gets a vendor-agnostic, pre-packaged automation platform. And even if a NetOps team has some semblance of network automation in place, Gluware can co-exist with homegrown scripts and traditional local device management.
Gluware’s automation platform brings pre-built intelligence to the network by solving the problem of having to develop everything from scratch. Rather than write and maintain a collection of scripts, network operators use a straightforward GUI called Gluware Control to manage the entire automation workflow.
Configuration Management and Modeling
With pre-built scripts, templates, and config-modeling functionality, an organization is most of the way there out of the box without having to write one line of code. And maintenance, or in other words, keeping syntax in line with the latest networking code version, is done by the Gluware developers, not a busy network operations team. Gluware calls this the “vendor adapter layer”, and it’s updated monthly to reflect any changes networking vendors make to their code.
It starts with an advanced network discovery by scanning subnets via a seeded device. From there, Gluware uses ARP tables, MAC tables, CDP neighbors, etc, to crawl the network and intelligently add nodes to a device inventory.
At this point, it can start modeling configuration snippets by breaking up monolithic config outputs like a “show run.” These snippets then exist as objects that are rendered in Gluware. Configuration is gathered over SSH, and it can be done out of band to minimize any impact on production.
This means config snippets are dynamically created and rendered by the platform itself, and this is what Gluware calls Config Modeling. And now that the network exists as a model, it can be easily manipulated and validated by gathering real-time information from the network, pushing configuration, and checking it periodically for things like config drift.
Network Validation
Gluware uses the terms pre-check and post-check in the context of assessing the state of the network, a process called Node State Assessment. Rather than manually entering a variety of show commands and parsing them in Notepad, a network engineer can leverage Gluware to first define what’s important to know about from the network, and then programmatically capture that information in real-time.
—
Automating configuration management gets exponentially more complex as networks scale, overlays are introduced, and when devices from multiple vendors are used. Even for engineers who have the skills to automate a complex network, the time to create homegrown scripts, maintain complex code, and keep up with vendor changes is a barrier many just can’t get around.
Gluware offers an intelligent management overlay that provides all the benefits of advanced closed loop network automation without having to re-tool an IT department, hire developers, or maintain code.
For more information about Gluware, watch their presentations from last February, 2020, at Networking Field Day 22 where they offer a thorough introduction to their platform and get into the weeds of how it works.
Thanks,
Phil
{networkphil} 