Controller Architecture: Northbound, Southbound, and Centralized State

A controller has two distinct sides. Northbound is the API you call — the interface exposed toward automation, dashboards, and integrations. Southbound is how the controller actually talks to the devices it manages — SSH, NETCONF, SNMP, vendor-proprietary protocols, or a mix. Your code never touches southbound directly; it's the controller's own concern.

Your codePython, using requests — nothing new here
Northbound APIthe only side your code ever touches
Controllerdecides how to actually reach each device
SouthboundSSH, NETCONF, SNMP, proprietary — opaque to you
Devices

Quick checkConcept check

Which side of a controller does automation code (like this module's own scripts) actually call?

Southbound — automation talks directly to devices through the controllerNorthbound — the API exposed toward automation; southbound (how the controller reaches devices) is the controller's own internal concernBoth sides equallyNeither — automation bypasses the controller entirely

Quick checkScenario

A controller manages both an old switch reachable only over SSH and a newer one that supports NETCONF. Does the automation code calling the controller's northbound API need to know which protocol reaches which device?

Yes — the code must specify SSH or NETCONF per deviceNo — that's exactly what southbound abstracts away; the northbound API looks the same regardless of how the controller actually reaches a given deviceYes, but only for NETCONF devicesNo, because all devices must use the same southbound protocol

Not "Ansible with centralized state"

This needs to be said directly, because the two can look similar from a distance: Ansible already handles many devices from one playbook. A controller is not just a bigger version of that.

Ansible (Phase 3.0)

Stateless orchestrationeach run re-derives what it needs
No persistent, centralized modelof the network's current state
You run the playbook when you decide to

Network Controller

Centralized, persistent statethe controller holds this continuously
Query current state anytimewithout triggering a new run
Asynchronous task/job lifecyclecovered fully in Lesson 4

The real distinction

Ansible orchestrates execution across devices, on demand, each run independent of the last. A controller maintains a standing, centralized model of inventory, state, and (often) policy — queryable at any time, not just during a run — and coordinates southbound device operations to keep reality aligned with that model. Both are legitimate; they solve different problems.

Quick checkMyth check

Is a network controller accurately described as 'Ansible with centralized state added on'?

Yes — that's a fair simplificationNo — Ansible orchestrates execution on demand with no persistent central model; a controller maintains a standing, centralized model of inventory/state (and often policy) that exists continuously, independent of any one automation runYes, but only for read operationsNo, because Ansible and controllers are completely unrelated

What a controller may add

capabilities a controller MAY provide

Centralized inventory   -- one queryable source, not per-tool device lists
Centralized state        -- continuously maintained, not re-derived per run
Policy / intent          -- describe desired outcome, not CLI steps
Task / job lifecycle     -- asynchronous, trackable (Lesson 4)
Assurance / observed state -- separately verifiable (Lesson 6)
Auditability / RBAC      -- who changed what, with what permission

Not every real controller implements all six identically — this list names what the architecture makes possible, not a guaranteed checklist for every product.

Quick checkIdentify the correct code

Which capability is specifically about being able to check a network's current state at any time, without triggering a new automation run?

Policy / intentCentralized stateRBACTask / job lifecycle

Key takeaways

Northbound is the API automation calls; southbound is how the controller reaches devices — invisible to, and irrelevant for, the calling code.
A controller is not 'Ansible with centralized state' — it maintains a standing, continuously-queryable model of the network, not something re-derived fresh on each run.
A controller MAY provide centralized inventory, centralized state, policy/intent abstraction, async task tracking, assurance, and RBAC/auditability — real platforms vary in which they implement.
Automation code only ever touches the northbound side, using the exact requests skills from Phase 3.1 — nothing new to learn there.

Controller Architecture: Northbound, Southbound, and Centralized State

What you'll learn

Two interfaces, one controller

Not "Ansible with centralized state"

What a controller may add