What is DevNetOps?

What is DevNetOps?

DevNetOps is the application of DevOps philosophies, principles, and behaviors to network operations (NetOps). DevOps philosophies originated with the software engineering culture and lean manufacturing revolution that occurred during the 1980s-2000s. These principles are commonly known as CALMS—culture, automation, lean, measurement, and sharing.

One of the most referenced DevOps principles counters the waterfall methodology—where extended planning, building, and testing cycles occur in long sequential stages. As documented in The DevOps Handbook, DevOps research has shown that for IT and manufacturing industries, smaller, more frequent deployments result in greater operational speed, agility, and improved quality.

For organizations to quickly meet their business goals, reliability is a key prerequisite! Speed without sustainability results in failure, and failing fast is beneficial to organizations only if they can improve between iterations. Coincidentally, a recent and popular implementation of DevOps is the site reliability engineer (SRE) role. Similarly, DevNetOps is implemented by the network reliability engineer (NRE) role.

What is a DevNetOps Pipeline?

DevNetOps Pipeline

DevNetOps Pipeline

To reduce the lead time between development and deployment, and work in shorter, faster cycles with smaller deployment change deliverables, the DevNetOps pipeline automates the progress between engineering changes and production deployments.

Committing to a versioned code repository triggers a continuous integration (CI) pipeline of progressive building and testing. Through a series of automatic and manual judgments, candidate delivery payloads are tested in virtual environments, simulations, and labs toward the state of a committed reliable delivery. The state of continuous delivery (CD) pipeline ensures that the committed delivery is always in a deployable state. Continuous deployment is the automatic push to staging and then production.

However, before changes are pushed into a runtime environment (such as staging and production), it is important to realize micro-sized architectural units of changes and immutable infrastructure. Large monolithic changes are not safe, and are slower to form and validate. Additionally, issues are harder to identify when compared to small packets of change.

Immutable infrastructure is equally important before continuous deployment. It is not efficient nor useful to deploy, and then have an engineer alter the meaning of what actually deployed. Production runtimes must be reproducible to safely test changes and determine how issues can be improved.

Continuous monitoring, measurement, and response comprise the last piece of DevNetOps. The in-production feedback to service-level indicators are used to make reactive or proactive adjustments to the transitory network state. Also, the analyzed telemetry, incidents, and external change requests feed continuous improvements back into the codified state of the networking systems.

Automated DevNetOps Pipeline Summary




Network as Code

Repos of configuration secrets, artifacts, and gitOps

Branching, reviewing, pairing, Agile

Code skills (not necessarily programming)

Pipeline Orchestration

Pipeline CI/CD tools, test frameworks

TDD, measurement judgments

Build and debug skills, pipeline pros

Micro and Immutable Architecture

Baking deliveries for ZTP, vendor refractors

Small-step commits/deployment

Hands-off CLI/TTY

Orchestrated Upgrades

ZTD, virtualization, labs, traffic draining

Staging and simulation canary analysis

In-hours maintenance, roll back or forward

Resiliency Design and Drills

Traffic generation, DoS, chaos monkey

Chaos windows, document limits

Force failure for understanding

Continuous Measurement

Big data analytics, ML, ITops integration

Incident playbooks, capacity planning

Management by stats, metrics, efficiency

Continuous Response

Auto-remediation, FaaS, predictive stats

Supervise self-driving

Engineer telemetry, indicators, self-healing

Continuous Improvement

Upgrades, features, fixes, changes

Record local lesson into global knowledge

Active open-mindedness post mortems

Benefits of DevNetOps

  • Team culture and behaviors consistent with reliability engineering combined with smaller, more frequent deployments lead to higher performing teams and companies1.
  • DevNetOps allows for speedier integration of vendor systems, especially software upgrades and patches. It persuades vendors to deliver in smaller payloads on a faster cadence, solving the problem of long lead time for features and fixes. It dramatically shortens the gap between the vendor’s time-to-market and operator time-to-deployment.
  • For engineers, DevNetOps reduces stress (deployment anxiety) and boosts job satisfaction.

What is the Relationship between NRE, DevNetOps, and DevOps?

DevOps and DevOps engineers are associated with business application development and operations. A role does exist for networking, especially for some types of software-defined networking (SDN), in running application clusters. However, networks also exist inside enterprises and service providers separate from the domain of developing and running software applications and platforms2. Some examples of NetOps networks which focus on enterprise applications are: wide-area backbone, transport, backhaul, and data center underlay networks.

To differentiate DevOps and DevNetOps, the separation of networking’s Dev-Ops is between vendor and customer instead of between teams of the same company. Some DevOps goals, such as rapid iteration of features and product experimentation, are not typical goals for the foundational infrastructure of networks. Nevertheless, DevOps principles and benefits apply equally to networking.

While DevNetOps, like DevOps, is a collection of philosophies, principles, and best practices, network reliability engineering (NRE) implements them. The “Dev” and “Engineering” goals are the same. However, while DevOps principles elevate the speed of iteration and evolution toward continuous learning, NRE focuses squarely on reliability as its foremost goal. These are complementary twin goals: a what and a why.