As the networking industry converges on a set of common components, the price variance between competing solutions is narrowing. This shift helps transition the dialogue from capital expenses (CapEx) to operational expenses (OpEx). While there are a number of contributors to OpEx, the biggest bogey for most organizations is network operations.
As a result, many in the networking industry are now looking to learn a thing or two from their cohorts on the server side, who have been using solutions such as automation frameworks to drive down costs for some time now.
Managing servers is an exercise in rapid, repeatable deployment. Like with any other technical exercise, accomplishing this task quickly and repeatedly requires a solid framework. DevOps provides that framework, along with a set of disciplines and software tools that make provisioning, validation, and deployment more automated.
A better understanding
The key to understanding DevOps is viewing infrastructure less as a collection of discrete elements managed individually and more as a distributed infrastructure managed by code. Each device, be it physical or virtual, is more like a function than a device. The configuration that drives each device’s behavior is analogous to the code that makes up a function.
In software, when functions are brought together, they create an application. In IT, when devices come together, they create an infrastructure. In either case, the end result is less about the components and more about the system. If the system is the central focal point, then DevOps is about managing that single system more effectively, thus driving down costs.
For some, the linkage between DevOps and software is a bit terrifying. Does this mean that network operations teams need to be rebuilt with software programming as a core competency? In a word, no.
Infrastructure
While DevOps is about treating infrastructure as code, it does not necessarily mean that your network operations team must become coders. The idea that infrastructure is code refers more to how device configuration is managed, validated, and deployed. If you think about device configuration as a standalone entity, you then manage your network device-by-device.
If you think about the whole infrastructure as a single system, then you treat the collection of configurations as a single system image. When changes are made, you compile those changes, test them and ultimately deploy them as one.
So how does this compare with operations today?
In a legacy networking environment, testing configuration changes is comprised of a set of manually executed health checks. Before leaving a change, you might ping a remote host, check the routing table and examine interface counters to make sure things are working. This is a bottom-up testing methodology.
The challenge with this approach is that the steps to validate it are highly contextual and change from task to task and even person to person. As a result, you end up relying on individual expertise and brute force to validate any changes. Knowing that not everyone has the same capabilities, many companies rely on maintenance operations protocols (MOPs) and standard operating procedures (SOPs) with an army of highly paid specialists backstopping the entire process.
In a highly-automated world using DevOps, testing is different. Rather than performing point checks around each change, you instead specify the desired behavior beforehand. For example, you should answer the questions: Which hosts need to be reachable? What routes need to be in the routing tables? What flows need to be on the network? What does QOS look like on all devices? Together these conditions form the foundation for a set of tests that are ultimately written against the network as a whole.
When you want to make changes, you make those changes to a development environment and execute the tests. You wouldn’t deploy software that didn’t compile correctly or that had bugs. Why would you deploy configuration changes that break your network? You wouldn’t, and DevOps helps prove correctness before those changes make it into production environments.
The key to evolving into this type of environment is actually less about the tools and more about understanding explicitly the expected network behavior. Nothing can be automated unless it can be specified and measured. Network teams that want to move to a more automated deployment model need to consider whether their network and surrounding infrastructure is appropriately instrumented for the shift. This will help clearly define failure and success.
Ultimately, DevOps might be identified by its tools, but it is really about a shift in methodology. Adopting a more agile, software-like approach to managing infrastructure will allow network teams to produce a network that is simultaneously more resilient and less costly to maintain.
- Michael Bushong, VP of Marketing at Plexxi
