This post, written by Ethan Banks, is sponsored by SolarWinds. We thank SolarWinds for supporting Packet Pushers.
Monitoring traditional network environments (routers, switches, firewalls, and so on) is a straightfoward activity. By and large, network engineers use SNMP, flow data, and syslog entries fed into a network management system (NMS) to keep track of the network. That NMS lets us know, at a glance, how the network is doing based on that data it’s gathering.
As long as we’re managing networks one device at a time, that approach makes sense. The NMS mirrors how engineers think about the network — as a system unto itself. However, IT is not about networks, at least not solely.
IT is about application delivery, and the network is only one component of a complex system delivering applications. As a result, monitoring across all silos has become more sophisticated, correlating events and statuses across all data center infrastructure to help us understand application impact. We categorize this generally as application performance monitoring.
However, life in the APM world is becoming even more challenging, as IT processes evolve in the face of orchestration and automation technology. For instance, software defined networking (SDN) has taken the notion of configuring network devices one at a time and turned it on its head.
Instead of an engineer logging into a switch and configuring a QoS policy, some piece of software might be pushing a QoS policy dynamically into several switches at a time based on live call demand as indicated by a UC server.
To see what’s happening, a network operator monitors software running on the SDN controller, and probably doesn’t look at individual switches at all.
Hmm. So, what does this do to our traditional NMS & APM? Does SDN mean that we don’t need to deal with an NMS anymore, or that we should shift our APM focus to SDN controller software? Will SDN replace our monitoring systems with something else?
To answer these questions, let’s consider what SDN actually does, insofar as we understand SDN in late 2015. SDN has a few key traits today.
- Software defined networking automates network configuration. The scope of this automation varies widely by application, but consider that SDN is more about making changes than monitoring infrastructure. Think about software defining the network as opposed to watching the network. This doesn’t mean SDN doesn’t have a monitoring component, as it does. But the primary goal here is making changes in accordance with an application requirement.
- Software defined networking helps humans to scale, and therefore networks to scale. How? SDN makes it feasible to deploy many virtual appliances and networks, more than a human could manage alone. Again, it’s about goals – and one main SDN goal is rapid scale, which goes along nicely with configuration automation.
- Software defined networking solutions tend to be point products. They tend to do one thing well, but are far from the unifying master controller that will handle all network infrastructure. The monitoring coupled with these solutions will reflect that, as it will keep up with the point solution adequately, but not have much to offer regarding the rest of the network.
Therefore, SDN does not replace network management, and it certainly does not replace more sophisticated application performance monitoring. If you think that SDN will someday just replace your existing network, you’re not thinking about SDN quite right. SDN is not an art kit you purchase to paint networking magic across the canvas of your data center.
Rather, SDN augments your network’s abilities. Even the most robust SDN products don’t claim to replace the entirety of your network infrastructure, and they definitely aren’t monitoring all of it. In fact, some SDN products can incorporate data from third-party monitoring systems to provide high-level status information to operators, and to supplement a controller’s awareness of the health of the SDN fabric. These SDN products can leverage an NMS as an information resource.
SDN doesn’t help us much with APM, either. Monitoring all the data center layers that need to be monitored, and correlating that data in the context of application delivery remains critical. SDN or not, the data center must deliver applications.
In my mind, this leaves monitoring vendors like SolarWinds in a good place. For instance, SolarWinds’ Application Stack Management Bundle remains a key tool for IT shops modeling application infrastructure dependencies. Nothing in the world of SDN takes that away. In fact, IT monitoring tools are likely to become more capable over time, as new SD-inspired data streams flow in from all parts of the data center.