The New Enterprise Requirement: Full Lifecycle Network Automation

Enterprise campus and access networks are growing increasingly complex at a pace far faster than companies can grow their available technical networking engineering support staff, who by the same token are becoming increasingly unaffordable. In this environment, automation is no longer an option: it’s become a mandate.

We got here by relying for too long on what I call the Legion of Legacy, meaning network infrastructure from the likes of Cisco, Juniper et al. The Legion was literally built on a Conservation of Complexity doctrine to lock customers into upgrade cycles and pricey support contracts. The Cisco Certified Internetwork Expert (CCIE) program, for example, was deliberately designed to be complicated, which I should know because, as one of Cisco’s first 100 employees, I was one of the people who helped put it together.

Unfortunately, complexity now rules the day. We have switches and routers with 20+ million lines of code. And consider this irony: the “Cisco EasyQoS Solution Design Guide” weighs in at more than 300 pages. “Jumbo shrimp,” anyone?

While the Legion of Legacy may tout new network management tools as a way to help automate enterprise networks, the tools themselves are so complex that they require more of the exact same scarce and expensive talent to operate them. There simply are not enough CCIEs on the planet, so you still hit the wall without having solved any of your underlying problems. Data and devices from IoT to mobile/BYOD are simply overwhelming the campus access edge while creating huge security concerns. And now 5G looms.

Automation: data center vs. wider enterprise

It’s worth pointing out that automation in enterprise campus and access networks is a far different animal from automation in the data center. Automation is well-established in the data center, where tools like the Open Network Install Environment (ONIE) and Zero-touch Provisioning (ZTP) work well over out-of-band management networks designed specifically for that environment.

Also, it’s far easier to deploy 5,000 or more of the same switch model in one building where all of your top support talent physically resides than it is to deploy 5,000 switches of multiple models and capabilities across hundreds of remote sites. Think of the data center as a climate-controlled environment, whereas access and campus networks are more like exercises in networking biodiversity. Different challenges completely.

SDN and Open Intent-based Networking

You may hear software-defined networks (SDN) touted as a possible solution to the complexity problem for the enterprise, but in its original form SDN focused on decoupling the control and data planes of an entire network, which has proven itself unworkable at scale and quite complicated in and of itself. Classic SDN also assumed a “dumb” underlying network, which is in contrast to the industry’s overall direction of moving to, ultimately, autonomous networks.

At its heart, the next step forward from SDN is more along the lines of intent-based networking (IBN), which takes some of the automation and control-based concepts of SDN and recasts it on a more digestible scale. This appears to be the right direction as it does allow for a degree of automation, but, in its current manifestation, it’s being served up by the Legion of Legacy as a “feature” to sell legacy switch upgrades, not to solve the existential complexity and lack of technical expertise problems.

A better path is Open Intent-based Networking (OIBN), born here at Pica8 in 2014, when we had the concept, just not the “IBN” term. OIBN enables all the same basic criteria commonly cited by IBN proponents, namely:

• Simplified operations, with centralized policy control, automated management and integrated IT workflows
• Enhanced security throughout the network to detect threats in real time
• Proactive management, including monitoring and analytics to pinpoint, report, and remediate problems
• Investment for future-proofing

But with OIBN you can easily add automated policies as well as swap out hardware or software whenever it makes sense from a cost/benefit/performance perspective. It’s the “open” part in OIBN that is the key differentiator as it works on an array of open network switches from multiple vendors, including Dell and many others.

Nymble: A path to full lifecycle network automation

Pica8 further adds to the OIBN automation canon with its just-announced Nymble™ automation framework. Based on the open-source Ansible automation framework, Nymble is a private cloud-based tool that enables enterprises to automate networking tasks, including switch software configuration and licensing; turning up VLANs; and MLAG, and performing health checks on all Power-over-Ethernet (PoE) devices. Users can either write up their own Ansible scripts or draw from a large library of Pica8-created Ansible “playbooks” that enable all sorts of tasks to be automated using simple English language commands.  This means, for example, that no programming skills (or CCIEs) are required to run Nymble in “Quick Start” mode for typical Day Zero tasks to activate and turn up hundreds of remote switches.

With Nymble and Pica8’s PICOS open, Linux-based network operating system, you’ll be on the path to a fully automated enterprise campus and access network, from deployment to ongoing operations. Moving forward, Pica8 will enhance Nymble and PICOS to provide full lifecycle network automation, only with zero vendor lock-down.

To learn more, come see us in booth 941 at Dell Technologies World, April 29 to May 2, 2019, in Las Vegas. Can’t make the show? Check out our white paper on Nymble. I think you’ll agree: it’s game-changing technology.