Digital transformation is requiring significant changes to the network, such that organizations need to think hard about just what it is that they want to transform and how they will use their “new” network. Because voice, video, data, and critical business applications are on the line, the network must be reliable. Otherwise, customers who have come to expect a high level of service will abandon your platform.

It’s vitally important to understand how the network handles applications and Quality of Service (QoS) policies. This means that how well the development and operations teams communicate and collaborate, is critical. In what seems like the Wild West of networking, is it possible for network engineers to take back control?

Taking a Page From DevOps

The world of software development provides a good example of how control might be possible. DevOps evolved out of necessity from the software world. With the waterfall development model, there was a lengthy period of product definition, and developers usually worked over a several-month period of testing 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 requirements and then push new iterations to the end user via the Internet. This began the trend of what’s now known as DevOps, a streamlining of the process from development to operations. With DevOps, you have to be continually developing, testing, integrating and deploying changes. It’s a constant cycle of innovation rather than a monolithic process.

In the same vein, networking is experiencing a similar phenomenon. You can’t take six months to get a feature out the door anymore. 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.

Ploughing up the Brownfield

Today’s network engineers have a handicap, though, because most of the installed base of brownfield networks still use command-line interface (CLI), which is not a programmatic interface. That means the way they’re interfacing and building their golden configuration files is an old-fashioned method that is not sustainable in today’s rapidly changing, agile network environments.

A significant amount of redundant labor is required 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.

That is to say, network engineers have lacked the tools that enable them to get into a continuous integration cycle in which development and operations work seamlessly together, while development continues to give operations what it needs, as it needs it – a real-time lifecycle.

However, the tricky part is that some of the newer protocols and products are not well defined. 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 migrational 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.

Taking Control Back

This is a difficult issue, but fortunately, there is a solution. 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:

1. Provides programmability with the network devices. No matter what resulting level of programmability, from development to lightweight scripting, SDNO 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 application program interface (API)/software development kit (SDK) or not (even with a telnet-only X.25 gateway).

2. Solves the standard protocol syndrome in which 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 the vendors. It also overcomes by design 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. 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 require 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.

3. Breaks vendor lock-in by using a combination of the two benefits above, making vendor hardware swappable.

4. Reduces the barriers to network functions virtualization (NFV) because the network is now 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.

Unite and Conquer

The only certainties in life seem to be death, taxes, and an ever-changing network. The way features are being implemented on the network are changing, so the infrastructure you need at the network layer to move from development to operations needs to resemble the software world’s movement to DevOps and its continuous integration cycle.

While it’s true that IT professionals need to continuously upgrade their skills, network engineers should not have to become software developers. What they need is means to orchestrate their networks in order to enable the full integration of modeling, building, testing, deploying to production, validating, and enabling the continuous integration cycle. In this way, the tension between development and operations is eased because they function together with a DevOps approach. This creates efficiencies, reduces costs, and enables a more fluid and rapid digital transformation.