Servers, especially Linux servers, have been managed programmatically for years. Today, it goes almost without saying that a decent IT department is running Chef, Ansible, or some other tool to manage their servers as pools of resources.
What strikes me as odd is that this didn’t catch on in the network side of the house. Of course, there are always exceptions. A look at networking forums from years ago will showcase a few ambitious engineers arguing over using Expect or Perl scripts to manage their switches, but this was the exception in the networking industry, not the norm.
At Networking Field Day 17, several vendors that have long embraced network programmability turned their gaze from the data center to enterprise networking, and it seems as if networking may be finally ready to catch up to what we’ve been doing with servers for decades.
In particular, Extreme Networks presented their philosophy of network programmability and what it should look like in action. Patrick LaPorte, Director of Product marketing for Network Automation, started with painting a picture of the “new” Extreme, which he described as focused on software-driven networking for the enterprise. Until recently, the idea of an automated network infrastructure has been in the context of the data center and WAN and concerned with device provisioning. Very few in the vendor community have expressed much interest in the campus and with ongoing network operations.
There’s great value using network automation for device provisioning. For example, for a switch refresh project, I’d start with reviewing with a customer their current switch configuration and developing a new base configuration for their new gear. Then I’d spend days copying and pasting that config onto switches while also recording switch information such as MAC addresses, hostnames, and management IP addresses into a spreadsheet.
This can take days or even weeks, and my spreadsheets become less reliable after so much copying and pasting. More than once I’ve skipped a device but not a line and completely botched a spreadsheet simply because of an administrative error.
Tools such as Ansible and Python make this much faster and more reliable, and Patrick alluded to this when he explained that, among other things, Extreme’s goal for their technology is to provide engineers a means for greater agility and efficiency in programming their networks.
But the specific problem isn’t the initial device provisioning. What Extreme is concerned with is the chokepoint between device provisioning and Day 2 operations. And herein lies the problem for many enterprise organizations. No one is disputing the benefit of network automation, but the skillset required to build entire automated workflows for ongoing network operations is difficult to come by. A typical enterprise like a regional hospital or local manufacturing facility often can’t afford or attract that kind of talent let alone realize there’s a better way to do networking.
Recently I’ve begun to see vendors package up the most common open source tools into a neat and tidy platform that abstracts away the code and presents network engineers a GUI to automate the network. As great as that seems, I don’t believe this is a new concept in networking. We’ve managed physical resources with this sort of interface for years using platforms such as Call Manager and our various wireless LAN controllers.
What Extreme is doing, however, is embracing the automation of an entire workflow including machine-to-machine automation and an open perspective able to accommodate multiple vendors. Ram Galla, a Senior Product Manager at Extreme, explained that he sees cross-domain automation as “not just provisioning per se, but how you integrate provisioning into the customer’s processes and tools.”
This is the right way to think about automation. It’s more than Day 0 provisioning, and it has to integrate completely into an existing network operations workflow presupposing some semblance of openness. Patrick and Ram were quick to explain that their Workflow Composer platform isn’t a closed system working only with their own devices, though it was designed primarily for their SLX, VDX, and MLX series switches and routers.
Instead, Extreme works with the open-source community and integrates with NAPALM in order to provide methods to communicate with non-Extreme CLI devices, execute actions in a multi-vendor environment, and integrate with a network team’s other tools to serve as the foundation of a completely automated network operations workflow. As one can see in the right side of the image above, even the code itself is made available for an engineer to examine and adjust according to their particular operational processes.
I believe they’re doing this right because they understand that many enterprise organizations will likely start with the automation platform alone and replace only the switches in one part of their network. This lowers the barrier to entry for a programmable infrastructure, makes buy-in easier from reluctant decision-makers, and decreases the potential failure domain if things go poorly.
I’m not interested in a closed automation system. I don’t much care for a controller-based pile of switches that requires I use only specific hardware, locks me into only the built-in automation templates, and doesn’t integrate with my existing tools. Something like that will end up being yet another platform that everyone is excited about for a few days and then never logs into again.
Network programmability is something the industry is embracing, and Extreme’s approach is to work with the community to provide an open platform that can fully integrate with a network operations workflow. Though it’s going to take time, networking is starting to catch up to what we’ve been doing with servers for decades.
Disclaimer: Gelstalt IT, the organizers of Networking Field Day, provides travel and expenses for me to attend Networking Field Day. I do not receive cash compensation as a delegate. Also, I do not receive compensation for writing about or promoting Networking Field Day.