homeblogdevops for networking

DevOps for Networking?

I was introduced to the world of DevOps in 2012, and I’ve never looked back. At Juniper Networks, I was part of the team responsible for putting a native Puppet agent onto a switch and developing the netdev Puppet module. The experience was a pivot point for my career. It changed the way I thought about solving complex network automation problems. Now I want to help bring DevOps to the networking community. But how?

A DevOps Eye for the Networking Guy

I asked my DevOp friends to share their history. How did the server admins many years ago make the transition to the highly productive automated infrastructure that they have today? They told me that there were not only technology changes, but more importantly, cultural changes.

I could appreciate the history lesson because I too made both a cultural and a technology change in my own career. I went from being a hardcore software engineer to a network systems/sales engineer. When my first sales VP asked how I was liking my new gig, I replied, “this is much harder than writing code.” That transition was a valuable lesson: to experience the other side. This is a lesson I see repeated in the culture of DevOps.

The image below is how I share the DevOps history with networking “NetOps” teams:

Image explaining how applications drive business

The key points I touch on:

  • Evolution takes time, not just a year or two, and is still in progress.
  • Platforms like Puppet are a pivot in the way people approach automation.
  • Platforms enable customers to focus on their problems.
  • Open source community drives innovation.

I would characterize the networking industry today as “pre-pivot” with respect to the DevOps evolution. Network engineers, if they are applying automation at all, are either doing ad-hoc scripting or are at a company that has a dedicated software engineering team building homebrewed systems for their use. Why has the network industry not yet moved through the pivot?

The biggest challenge with network automation, I believe, is that networking infrastructure is a Tower of Babel problem. Legacy networking “operating systems” are actually highly integrated vertical sets of software that include an “OS,” “middleware,” and “applications.” Here’s how I describe the nature of networking systems to DevOps folks:

Consider networking (services) as a multi-tiered, distributed application. There are multiple OSs, different command interfaces, interrelated distributed applications, and multiple “databases.” If you were to think of networking in this context, how would you solve network automation using today’s DevOps tools?

So how do we approach moving through the pivot? What is missing and what can we do? While there are many facets to these questions, I will outline the big three that I see time and again.

Missing Technology: Tools

I would describe most of today’s DevOps tools (like Puppet) as “Big-C, Little-E” — meaning, these tools are focused on solving Configuration Management (Big-C) automation, but don’t have much to do with ephemeral state automation (Little-E). Ephemeral state data is not configuration, but the result of configuration. For example, you can configure an interface to be “up,” but the ephemeral state of the interface is either “up” or “down,” depending on the physical link.

Given that networking services are multi-tier distributed applications, the art and science of troubleshooting a network or enforcing a Service Level Agreement (SLA) is all about ephemeral state. For example, if I add a route on one side of the network, I need to ensure that route shows up at the other side (or at many points) so that my fancy new overlay-network software can route across the entire physical infrastructure.

Call to action: Customers need multi-vendor automation tools that solve the use-case workflow patterns for networking. They need both “Big-C, Little-E” tools and “Big-E, Little-C” tools. Perhaps existing DevOps tool vendors can adapt their technology. Perhaps 2014 will bring new network automation tools to market. The challenge in the marketplace historically has been network manufacturers focused on creating product differentiation, which is counter to multi-vendor.

Missing Technology: Automation of Dev-Test Environment

Another topic that comes up a lot is a developer-test environment for creating network automation solutions. Server virtualization has made an enormous positive impact on DevOps’ ability to “software QA” their automation systems. It is an expensive endeavor to create a test lab of network equipment, and there have been some great advances in the area of virtualized network environments for simulation, training, and automation dev-test. These environments, however, do not always enable a multi-vendor collection of virtualized infrastructure. Given the distributed, multi-tier application nature of network automation use-cases, creating a suitable environment is a big, big challenge.

Call to action: This is tough because of the very nature of networking infrastructure. Perhaps smart people can look at the problem and figure out how to use the vast array of virtualization technologies and the existing vendor solutions in a way that delivers a dev-test environment. If you’re out there, let me know. I’ll be your first customer!

There are also advancements in Network Function Virtualization (NFV), and using Linux as the network OS; both are decoupling hardware, OS, middleware, and applications. These are exciting areas to keep an eye on.

Missing Culture: Paying for Automation Tools

People want to buy tools to get a job done. When you buy a dishwasher, for example, you don’t buy the hardware and software separately; you want to buy the complete package knowing it will wash dishes. Will customers pay more for network automation tools from the equipment vendor to make the networking user experience better? If a networking customer is spending a lot of money on the physical equipment, they often do not put a value on additional software tools from the vendor, even if the network engineers really want them. Perhaps there is a disconnect between the network engineering teams that need the tools, and the decision makers who pay for them.

After spending many years as a networking sales engineer, I have generally seen value attached to network automation tools if they are multi-vendor in nature and can be directly tied to the value chain of the end customer. If we look at DevOps tools like Puppet, these tools satisfy that value requirement.

Call to action: This is partly a technology/tools problem as well. Perhaps when there is a rich ecosystem of network vendor-independent tools, the decision makers will start paying for these. Even though some of these tools exist in niche spaces (such as security-firewall), it is still often a daunting sales task to convince a customer to pay for software that will make their hardware easier to use.

Looking Forward into 2014

I am hopeful that 2014 will be the year of grand IT automation convergence. DevOps as a culture and community is absolutely forefront. Finding a way to bring DevOps and networking together will happen. There are already many grassroots efforts taking shape to help network engineers level up on technologies, tools, and automation skills. Look around, and perhaps you’ll find a Meetup group near you.

Call to action: If you don’t have a Meetup group in your area, start one. If you need help, let me know.

About the author: Jeremy Schulman is the director of automation concept engineering at Juniper Networks. With 20 years in the networking industry, his prior roles included embedded software engineering, sales/systems engineering, business development, and now an exclusive focus on automation. He is often in the field talking with customers, partners, network engineers, and DevOps about applying automation technologies to networking. Jeremy is also an active contributor to open source software projects. You can follow him on Twitter.

Disclaimer: This is a guest blog post. Views expressed in this post are the original thoughts posted by Jeremy Schulman, director of automation concept engineering at Juniper Networks. These views are his own, and in no way represent the views of the company he works for.

Learn More