Editor's Note: This article on DevOps is one of a set that can be found, along with videos and other resources, within the SDxCentral DevOps Topic. Check this Topic regularly to see the latest updates.

One of the hallmark principles of DevOps is the expression of the system as source code. In networking, this means expressing what is normally specified in discrete device configurations as a collection of source code instead. The challenge here lies not in collecting configuration and storing it centrally, but rather in dealing with the device-specific nature of networking. Abstractions play a key role in providing a shared way to understand specific network behaviors and constructs.

On most networking devices, configuration reflects the underlying implementation, which is tied in part to the hardware. Networking does not have a universal, vendor-agnostic way to describe things like Layer 1/Layer 2/Layer 3 interface properties, VLANs, route tables, or even routes. Edge policy, in particular, is notoriously device-dependent. No common language exists for concepts such as quality-of-service (QoS), even across platforms from a single vendor.

Providing a shared way to reference specific network behaviors is the first step to automation. This requires abstractions for legacy networking concepts. In networking DevOps today, these abstractions are starting to take form. For example:

• Puppet is using the Netdev abstraction framework developed by Juniper Networks.
• Chef is using a ported version of the Netdev abstractions.
• OpenStack is using the abstractions in its Neutron project.
• OpenDaylight has abstractions through its Affinity Metadata Service.

Some abstractions, like the first three groups of abstractions listed above, are designed to simplify the provisioning of network elements. Networking constructs like VLANs, for instance, can be translated into device-specific configuration using the parent tools or frameworks. The objective in providing these abstractions is to allow provisioning to be captured as source code that is triggered either manually or automatically by an external system.

The OpenDaylight abstractions represent the expansion of abstractions into the application space. The Affinity Metadata Service is designed to allow the expression of application requirements such as bandwidth and latency in non-networking terms. These abstractions are consumed by the networking infrastructure, which then can adjust behavior according to application demand.

OpenDaylight's Affinity Metadata Service is just one part of an emerging class of abstractions being driven by SDN. The space likely will evolve rapidly as additional application and flow abstractions are developed.

The question for DevOps practitioners then becomes: If automating all the things requires a common semantic to describe behavior, how will DevOps for networking emerge if there are multiple competing abstraction models?

DevOps as a practice in networking is still nascent. It is unclear what tools and frameworks will emerge. The ecosystem as it stands is fractured, with different groups flocking to different tools based largely on what is common practice in other areas of their IT operations. For most people becoming familiar with DevOps for networking, it makes good sense to leverage existing practices elsewhere in the company. For those who do not have existing practices, it is worth examining the various tools to understand the pros and cons of their individual approaches.

One group worth watching in particular is the Netmod (Network Modeling) group in IETF. This group is using the Netconf protocol to produce traffic models that can be used as inputs into management systems. This architecture already is being used by OpenDaylight, meaning interested users can gets their hands on working code today.

Longer term, the question needs to focus on how abstractions ought to evolve. In the fullness of time, is the model going to be the expression of network behavior entirely via abstractions? Or will users instead specify application requirements that will be used by control systems to devise appropriate network behavior? While the assumption might be that the latter concept is too complex, perhaps groups like Netmod and others will succeed in making it a reality.