During one of the keynote presentations at Cisco Live 2017, I had the privilege of briefly speaking with Rowan Trollope and Angela Ollig (at 52:50). Angela was recognized as the newest attendee at Cisco Live, having recently graduated with a degree in IT management from the University of Wisconsin-Stout and attending her first Cisco Live. My participation was as the longest attending Cisco Live (formerly Networkers) participant, with more than 20 conferences under my belt. My evidence is my collection of hats that are handed out at the customer appreciation event each year. Yes, I’ve kept all of them.
During the brief conversation, Rowan asked if I had any advice for Andrea. My reply was, “Hang onto your hat.” There was the obvious meaning of hanging on to your Cisco Live hat, but there’s another meaning that’s more important for this audience.
The Network Is Changing
Hold on to your hat because the pace of network innovation is accelerating. For many years, we’ve experienced evolutionary changes in networking. We have some overlay technologies now. There are different methods of Layer 2 networking that eliminate the risk of the Spanning Tree Protocol. Leaf-spine network designs are making their way into the data center.
A burst of activity occurred when software-defined networking made a big splash, around 2011. We’ve seen some advances as a result, but it is still mostly evolutionary progress. Networks still base their forwarding decisions on the destination IP address, unless you build complex configurations to work around it. These complex configurations make the network configuration fragile.
Other parts of IT, servers and storage in particular, have made significant progress in simplification. Virtualization and the tools to manage it now allow a single administrator to oversee hundreds of server instances (VMs).
Networking has been stuck with mostly manual processes. One reason is that we teach individuals how to configure a single box — a router, switch, firewall, or load balancer. We don’t do a good job of teaching them how to leverage automation to control the network as a system. Most of the network management tools still look at individual boxes and interfaces, and these same management systems require a lot of manual configuration.
We use change control boards to make fewer mistakes when implementing network changes. The result is that the pace of those changes slows down — and cannot keep up with the rest of IT. We need something different if networking is going to catch up. Instead of configuring the network using incredibly detailed configurations, one box at a time, we need systems that control the network as a system.
Intent-Based Networking Systems
Gartner started covering a new category of system called intent-based networking systems (IBNS) early in 2017. There are just a few vendors making products in this space. Then Cisco announced their plans for IBNS the week before Cisco Live, creating buzz around the term. What does it mean?
A good example is Amazon’s AWS. Let’s say we need a compute node, medium capacity, to perform some analysis. We tell AWS what CPU capacity we want, how much storage to allocate, and whether we want a private or public address. In a few minutes, we have access to the new system, including a secure connection over the internet. There’s no need to specify all the networking configuration. It happens in the background and we don’t need to be concerned about it. We specified what we wanted, not how it’s configured. A good system will monitor the compute that we just created and move the processing to a new hardware platform if the old one fails. Our networks need to be like this.
What Are the Implications?
Networking teams will need new skills, which implies new education. They need support and encouragement from corporate executives, which translates into encouragement to learn and the time to learn. Most vendors now support VM implementations of their main products and for reasonable amounts of money; it is possible to create a virtual instance of important parts of your network. The network team can then use the virtual instance to learn how to use automation and validate changes before deployment.
This is a journey that will take time. The path may need to include spending time with network automation tools like Ansible and SaltStack. The server staff may already be using these tools, which may make the transition easier.
One of the big impacts will be changes in processes. The change control board process will need to change if the network is to become more agile. The network staff will have to become accustomed to new processes for validating and rolling out changes. They will need to work with software developers who can create self-serve portals that allow the IT teams to easily request and implement simple network changes like those performed by AWS.
It’s an exciting time. Changes can be a source of turmoil or they can be a source of opportunity. You get to decide how to handle it.