All businesses today are moving towards digital transformation. Gartner calls it the DigiFlip. When you digitize your business, your booking systems are online, as are your resource management and HR systems, etc. The rapid changes of the network also have to do with how the business wants to use the network, and if this includes voice, video, data, or critical business applications, it better be reliable or people will abandon your platform. Networks are evolving and customers are demanding a higher level of service.
How the network handles applications and Quality of Service (QoS) policies, as an example, is of paramount importance, which 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?
The Evolution of DevOps Management
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 Agile, 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 keep iterating and adding to it. This started the trend of what’s now known as DevOps, which is 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.
A similar phenomenon is happening in networking. You can’t take six months to get a feature out the door anymore. If your terms of service or a business line need something in the network, you need to get it to the network as soon as possible. That’s where networking engineers are at right now.
Transitioning Brownfield Systems
A significant limiting factor for network engineers today 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 network environments.
In a multivendor network, there is a lot of overhead. 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.
For the most part, network engineers haven’t had the tools that enable them to get into a continuous integration cycle in which Development and Operations work seamlessly together, and Development is continuing to give Operations what it needs, as it needs it – a real-time lifecycle.
Yet, here’s the rub: Some of the newer protocols and newer products are not well-defined, and the tools built to interface were created for the new generation and don’t work with the 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, but the smaller organizations are stuck throwing employees and expensive contractors at the problem, or just not meeting their business line needs.
Regaining Control of Network Functions
What is the solution to this dilemma? 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.
First, SDNO provides programmability with the network devices. No matter what 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).
Second, SDNO provides ways 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? The SDNO solution should provide the ability for the model to capture 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/semantics. Network operations merely apply the network model. That’s it. For instance, switch vendors all support VLANs. However, 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 it needs 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.
Third, as the result of combining the first two benefits, SDNO offers the ultimate way to break vendor lock-in, making vendor hardware swappable.
Fourth, as the network is now a set of multiple features or functions, the path to NFV is easier. 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. The SDNO solution will configure both with your expected network design.
Enabling DevOps Functionality
The only thing that’s consistent in the network is change. Business fees are changing and the way you’re implementing features 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.
Network engineers are not software developers, nor should they have to pretend to be. Engineers today need an orchestration platform that enables the full integration of modeling, building, testing, deploying to production, validating, and enabling the continuous integration cycle. This model reduces friction between Development and Operations. Whereas formerly these teams would be at odds, development and operations work closely together in a DevOps model. Operations provides feedback to Development, and they have a relationship that minimizes overhead, inefficiencies and the process of getting changes out to production.