Reducing the Friction of Network Change with the DevOps Model

As networks evolve, customers are demanding a higher level of service. How the network handles applications and Quality of Service (QoS) policies is of paramount importance, which means that the Development and Operations (DevOps) teams must communicate and collaborate as seamlessly and efficiently as possible. In what seems like the Wild West of networking, is it possible for network engineers to take back control?

One way they can regain control is to take a page from the software world, where the DevOps approach emerged. With the Waterfall development model, there was a lengthy period of product definition, and developers usually worked over a several-month testing period to essentially develop a monolithic configuration file. Agile was the next evolution in software development, in which there is an understanding that requirements are going to frequently change. The idea is to get something out the door that meets the current requirements, and then push new iterations to the end user via the internet. This began the trend of what’s now known as DevOps, which is a streamlining of the process from development to operations. With DevOps, you must be continually developing, testing, integrating and deploying changes. It’s a constant cycle of innovation rather than a monolithic process.

Networking is experiencing a similar scenario. You no longer have the luxury of taking six months to get a feature out the door. If your terms of service or a business line requests changes, you need to get it to the network as soon as possible. That’s where networking engineers are at right now.

The Brownfield Dilemma

A sticking point in this transformation process, though, is that most of the installed base of brownfield networks still use CLI (command-line interface), which is not a programmatic interface. That means the way they’re interfacing and building their golden config files is an old-fashioned method that is not sustainable in today’s rapidly changing, agile network environments.

There is a lot of repetitive work necessary in a multi-vendor network. If you have to configure something for Vendor 1, and you transition over to Vendor 2, you have to do essentially the same configuration, but it’s slightly different. That makes it a little tougher for engineering; it’s essentially the equivalent of learning how to drive a car with an automatic transmission and then suddenly having to learn to drive a stick shift. It can be done, but it’s clunky and requires more time and effort.

Network engineers typically don’t have the tools they need to get into a continuous integration cycle in which Development and Operations work seamlessly together while Development gives Operations what it needs, when needed. In other words, a real-time lifecycle.

The tricky part here is that some of the newer products and protocols are not well defined, and the interface tools were created for the new generation and don’t work with old-generation networks. Because most organizations can’t afford to start from scratch, they are going to have to undergo a migration phase as they transition their brownfield systems. The large service providers have the budget and big development teams to painfully move through this transition, while smaller organizations are stuck throwing employees and expensive contractors at the problem, or worse, not meeting strategic business line needs.

Orchestration Provides Control

Fortunately, there is a way to overcome this problem. Instead of making changes manually for each vendor, network engineers can move toward software defined network orchestration (SDNO). Through SDNO, network designs are created using modeling, and it solves multiple problems:

SDNO offers methods to address the “standard protocol syndrome,” where a protocol exists across vendors but their implementation differs (from proprietary extensions to configuration specifics). Wouldn’t it be nice to have a single model that works across multiple vendors? Advanced SDNO solutions should enable model captures of each implementation (this is a one-off task). Then network operations can ignore the underlying nightmare of understanding the differences between vendors. It also by design overcomes the nightmare of dealing with versions, licenses and syntax/semantic. Network operations merely apply the network model. That’s it. For instance, switch vendors all support VLANs (virtual local area networks). But some vendors apply VLANs to ports and some others proceed the other way around by adding ports to VLANs. At the end of the day, network operations need a unique way to deploy VLANs no matter how they need to be implemented at the vendor level. The SDNO engine will execute the VLAN deployment network model and configure each vendor accordingly, based on the network operations VLAN/Port map they desire.

SDNO enables programmability with the network devices. Regardless of the resulting level of programmability, from development to lightweight scripting, it offers a better approach for interacting with the device: condition management, state awareness and, most importantly, scale – the ability to distribute across multiple targets very quickly. A good SDNO solution should be able to provide this programmability across all vendors, whether the latter provides API/SDK or not (even with a telnet-only X.25 gateway).

Due to a combination of the first two benefits, SDNO frees organizations from vendor lock-in, making vendor hardware swappable.

The path to NFV is easier now that the network is a set of multiple features or functions. At the end of the day, what matters is the VLAN map you want to deploy. It does not matter if it ends up running on a particular switch vendor or an open source virtual switch. Next-generation SDNO solutions should configure both with your expected network design.

Together for the Greater Good

Change is the only constant when it comes to the network these days. A DevOps-like continuous integration cycle will help in the transition from Development to Operations.

It’s too much to ask network engineers to become software developers, and with the DevOps model, it’s not necessary. Instead, they can make use of an orchestration platform that enables the full integration of modeling, building, testing, deploying to production, validating and enabling the continuous integration cycle. This model enables Development and Operations to work together as a team focused on the same goal. In this environment, organizations stand to save money, streamline workflows and get changes out to production in a timely manner.