The platform that touches the network is where automation succeeds or stalls.

What the work looks like

Service models operators actually use, with the inputs they have and none they do not. Templates and code that produce a readable dry-run diff. Verification before and after, so the automation can report whether it worked rather than assume it did.

And the unglamorous part: driver and platform upgrades on a cadence, a version matrix kept current, and a lab that proves an upgrade before it touches production.

Cisco NSO

Service packages in YANG with Python or template mappings. NEDs selected and upgraded deliberately. Brownfield devices reconciled with sync-from, compare-config, and service re-deploy reconcile, so existing config becomes service-owned without being rewritten. Every package change goes through git and a netsim pipeline that runs a dry-run diff on the merge request.

module vlan {
  namespace "http://example.net/vlan";
  prefix vlan;
  import tailf-ncs { prefix ncs; }

  list vlan {
    key name;
    uses ncs:service-data;
    ncs:servicepoint vlan-servicepoint;

    leaf name    { type string; }
    leaf vlan-id { type uint16 { range "1..4094"; } }
    leaf-list device {
      type leafref { path "/ncs:devices/ncs:device/ncs:name"; }
    }
  }
}

Cisco Crosswork

Change Automation playbooks built around the maintenance windows operators already run, with pre-checks and post-checks as plays of their own rather than afterthoughts. Workflow Manager flows that take a ticket in and hand evidence back. Network Controller fed the inventory and telemetry it needs to be useful rather than decorative.

NetBrain

Runbooks and intent checks that run before and after a change, triggered from the ticketing system through the API rather than by someone remembering. Maps that stay current because they are part of the change process instead of a one-time import.

Forward Networks

Intent checks and path queries wired into the change pipeline, so a change that breaks reachability or isolation is blocked before it ships. Snapshots taken on a schedule and kept as the evidence trail for compliance.

$ curl -s -u "$FWD_KEY:$FWD_SECRET" \
    "https://fwd.app/api/snapshots/$SNAP/checks?status=FAIL"
[]
$ curl -s -u "$FWD_KEY:$FWD_SECRET" \
    "https://fwd.app/api/snapshots/$SNAP/paths?srcIp=10.42.0.10&dstIp=10.88.0.10"
{ "info": { "paths": [] }, "timedOut": false }
isolation holds: no path from cust-1042 to cust-0988

NetStacks Controller

When a client needs MOPs with approvals, a credential vault, session recording, or a terminal the whole NOC shares, we deploy our own controller next to whatever orchestrator they run. It reads NetBox, talks NETCONF, gNMI, and REST to the devices, and keeps the evidence for every change. We built it, so we know exactly where it fits and where it does not.

Everything else

The same approach applies to Juniper Paragon, Ansible, and the in-house Python most teams already have more of than they would like. The platform matters less than whether a change can get from a request to a router without a person typing it.

Common questions

Does NetStacks resell these platforms?

No. We carry no vendor quota and have no reseller agreements with any of them. If the platform the team already owns can do the job, the work is to make it do the job.

Can you work alongside a VAR or the vendor's team?

Yes. We usually end up as the party that connects what they delivered to what operators do day to day.

Is a source of truth required before starting?

No. Start with what the network reports about itself and one workflow that does not need a perfect inventory. Build the source of truth as the workflows demand it, not before.