1. Introduction

A single coherent transponder reports more than 200 metrics every second — optical power, OSNR, chromatic dispersion, differential group delay, pre-FEC and post-FEC bit error rates, laser bias current, temperature. A metro region with a few hundred line cards generates millions of telemetry updates per second. No team logs into those devices and reads that by hand, yet the configuration that produced those metrics was, until recently, typed in one SSH session at a time. That gap — machine-scale state, human-scale change — is what NetDevOps closes for optical operations.

NetDevOps applies the practices software teams settled on years ago — version control, automated testing, continuous integration and delivery, infrastructure described as code — to the network itself. The configuration of a ROADM, an amplifier chain, or a transponder stops being a thing an engineer remembers how to type and becomes a file in Git that a pipeline validates, deploys, and verifies. The point is not novelty. It is that optical network complexity has grown past the scale at which manual operations keep pace: coherent pluggable optics at 400G, 800G and 1.6T, C+L band expansion that doubles the channel count an amplifier must hold flat, and AI-driven traffic patterns that move faster than a change-control ticket.

This article lays out how to make that transition without breaking the network in the process. The governing idea is sequence. You do not flip optical operations from CLI to code in one release; you move read-only first, then controlled provisioning on segments where a mistake is survivable, then closed-loop optimization once the first two have earned trust. Underneath sits a specific toolchain — Python as the language, Ansible for fleet configuration, Nornir for when Ansible runs out of road — and a specific protocol stack — NETCONF for transactional change, gNMI for streaming telemetry, RESTCONF for lightweight integration.

The harder half of the transition is not technical. It is the team. The recurring finding across operators who have done this is that teaching Python to a network engineer who already understands OSNR budgets and ROADM behavior is faster and cheaper than teaching optical physics to a software developer. That choice — who you train, what you budget, how the culture shifts — decides whether the automation survives its first outage. We will treat it as a first-class engineering problem, not an afterthought.

2. What NetDevOps Means on the Optical Layer

The CLI is an imperative interface: you tell a device what commands to run, in what order, and you hope the running configuration ends where you intended. NetDevOps replaces that with a declarative one: you describe the desired state — this wavelength on this channel, this launch power, this amplifier gain target — and a system drives the device to that state and reports whether it got there. The difference matters most when something goes wrong halfway through. A CLI script that fails on line forty leaves the device in a state nobody designed. A declarative, transactional change either lands completely or rolls back to where it started.

Four practices carry over from software DevOps, and each maps onto a concrete optical-operations problem.

Version control as the source of truth

Every intended configuration lives in Git, not in an engineer's head or a device's NVRAM. The running configuration of the network should be reconstructable from the repository at any commit. This is what makes a change auditable — you can see who proposed a launch-power adjustment, who reviewed it, and what the network looked like before and after. It is also what makes rollback meaningful: reverting a commit and re-running the pipeline is a defined operation, not an act of memory.

Configuration as code

A wavelength provisioning request stops being a runbook and becomes a templated artifact — a Jinja2 template rendering device-specific configuration from a small set of parameters (endpoints, channel, modulation format, target power). The same template, fed different parameters, provisions every similar service the same way. This removes the per-device variation that creeps into manual work and is the source of most configuration drift.

Continuous integration: test before you touch the network

Before a rendered configuration reaches a device, a CI job checks it: does it parse against the device's YANG model, does it reference channels and ports that exist, does it violate a power or spectrum constraint. Much of this can run against a model or a digital twin with no production device involved. The discipline is the same one software teams use — catch the error on the build server, where it costs nothing, not in the network, where it costs a service.

Continuous delivery: a reconciler, not a cron job

Delivery is a loop, not a one-shot push. A reconciler compares declared intent in Git against observed state from telemetry and drives the difference to zero — applying the change, reading back the result, and either confirming or reverting. Network-as-Code for the optical layer is exactly this loop closed around the candidate datastore and confirmed-commit mechanics we cover in Section 5.

Why declarative beats imperative on optics: An imperative CLI macro that sets amplifier gain, then channel power, then turns up the wavelength has three points where a partial failure leaves the photonic layer in an undefined state — and on a live C+L line, an undefined launch-power state degrades every adjacent channel sharing that amplifier. A declarative change validated in a candidate datastore commits all three as one transaction or none.

Standards framework the practices rely on

NetDevOps on optics is only possible because the interfaces underneath it are standardized. NETCONF (IETF RFC 6241) provides transactional configuration with a candidate datastore and atomic commit. YANG (IETF RFC 7950) is the modeling language that defines what those configurations can express. RESTCONF (RFC 8040) exposes the same YANG data as HTTP resources for lighter integrations. gNMI, defined by the OpenConfig operator working group over gRPC, carries both configuration and high-rate streaming telemetry. The datastore concepts these share were later formalized in the Network Management Datastore Architecture (RFC 8342). For optics specifically, two model families fill the YANG contract: OpenConfig and OpenROADM. The transport-orchestration boundary above the controllers uses ONF's Transport API and OpenConfig models.

Takeaway: NetDevOps is not a tool you install. It is four practices — version control, configuration as code, CI, and CD — that together turn network change from an imperative act of typing into a declarative, testable, reversible transaction. On the optical layer the candidate datastore is what makes that transaction safe; without it, automating the CLI just automates the risk.

3. The Toolchain and Where Each Piece Sits

The mistake that stalls most optical-automation programs is reaching for one tool to do everything. Python, Ansible, and Nornir are not competitors; they sit at different layers and solve different problems. Understanding the boundaries between them is what keeps a toolchain coherent as it grows.

Premium Article — Free 21% Preview

Read the Full Analysis with Premium

The remaining 79% of this article — the design numbers, trade-offs and field guidance — is part of MapYourTech Premium, along with the full premium library, courses and professional tools.

Instant access · Cancel anytime · 48-hour trial available
Sanjay Yadav

Optical Communications & Network Automation Expert | Author of 3 Books for Optical Engineers | Founder, MapYourTech

Optical networking engineer with nearly two decades of experience across DWDM, OTN, coherent optics, submarine systems, and cloud infrastructure. Founder of MapYourTech.

Follow on LinkedIn

Related Articles on MapYourTech