As the Network Changes, Engineers Are Embracing the DevOps Model

Featured article by Olivier Huynh Van, CTO and Co-founder, Glue Networks

Businesses that have embraced digital transformation with a clear strategy are outperforming their peers. A Capgemini study found that digitization leaders generate more revenue, are more profitable and enjoy higher market valuation. This transformation requires making rapid changes to the network without taking critical systems offline – no easy task. An organization succeeds at this process when its customers are unaware that the changes are taking place because no services are being disrupted.

As customers demand a higher level of service, how the network handles applications and Quality of Service (QoS) policies is of paramount importance. That means how well the Development and Operations teams communicate and collaborate is critical. In what seems like a rough-and-tumble networking environment, is it possible for network engineers to take back control?

The Birth of DevOps

Since necessity is the mother of invention, the software arena birthed DevOps, a streamlining of the process from development to operations. 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.

The next transformation in software was the Agile approach, 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 DevOps, where you have to be continually developing, testing, integrating and deploying changes. It’s a constant cycle of innovation rather than a monolithic process.

Now it’s time for networking to undergo a metamorphosis. It’s not possible to 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.

Clunky Network Problems

What makes networking change difficult is the fact 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.

Engineers have a lot of tricky work to do if they have 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 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.

A real-time lifecycle is the Holy Grail these days, but network engineers have not typically had 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 big problem here is that the newer protocols and products were created for the new generation and don’t work with legacy 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 Back Network Functions

The answer to this problem is to begin automating the mundane. 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 provides multiple benefits:

1. SDNO delivers programmability with the network devices. No matter what 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).

2. SDNO fixes the typical protocol issue 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 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 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.

3. By combining the first two benefits, SDNO alleviates vendor lock-in, making vendor hardware swappable.

4. Because the network is now a set of multiple features or functions, SDNO lowers the barriers to NFV. 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.

The Power of DevOps for the Network

Change is the only constant in the network. How you implement features on the network is 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.

Software developers and network engineers do not serve the same function, but the latter can learn and benefit from the software world. The DevOps model brings together Development and Operations, reducing friction between the two departments. This model is empowered by the use of an orchestration platform that enables the full integration of modeling, building, testing, deploying to production, validating and enabling the continuous integration cycle.

About the author:

Olivier Huynh Van is the visionary inventor of Gluware technology and leads R&D for Glue Networks. Previously, Olivier was the CTO of Yelofin Networks, and has 20 years’ experience designing and managing mission critical global networks for ADM Investor Services, Groupe ODDO & Cie, Natixis, Oxoid and Deutsche Bank. Olivier holds a Master’s Degree in Electronics, Robotics and Information Technology from ESIEA in Paris, France.