NSO and Ansible: where each fits in intent-based automation

"Should we use NSO or Ansible?" is a question we hear often — and it usually contains a false choice. Cisco NSO and Ansible aren't competitors fighting over the same job. They're tools with different centers of gravity, and the strongest automation practices use both, each where it's strongest.

Framing them as rivals leads to bad architecture in both directions: teams stretch Ansible to do transactional service orchestration it was never built for, or they push every trivial device task through NSO's modeling overhead. Understanding what each is actually good at makes the division of labor obvious.

What Ansible is good at

Ansible is agentless, approachable, and enormously flexible. Its strengths:

• Task and configuration automation — pushing config, running commands, gathering facts, bootstrapping devices.
• A low barrier to entry — readable YAML playbooks that a broad team can contribute to, not just specialists.
• A vast module ecosystem — network vendors, cloud, Linux, and the systems adjacent to the network.
• Glue — orchestrating steps across tools, triggering scripts, wiring pipelines together.

Its model is essentially procedural: run these tasks, in this order, to reach a desired result. That's perfect for device-level configuration and day-2 operations. It's less suited, on its own, to network-wide services where you need transactional guarantees and automatic rollback across many devices at once.

What NSO is good at

Cisco NSO (Network Services Orchestrator) is built for a different altitude. It is model-driven — services and devices are described in YANG — and its defining strength is treating a network-wide change as a single transaction:

• Service-level abstraction — you declare the intended service (an L3VPN, say), and NSO renders the per-device config across a multi-vendor network.
• Transactional integrity — a service change either fully applies across all devices or rolls back cleanly. No half-configured networks.
• Reconciliation of intent vs. actual at the service layer — NSO knows what it deployed and can detect and correct divergence.
• Multi-vendor consistency — one service model, many device types, via Network Element Drivers.

The differences that matter

Three distinctions decide which tool fits a given job:

1. Procedural vs. declarative-transactional. Ansible runs steps; NSO maintains a modeled, transactional view of intended service state.
2. Device task vs. network service. Ansible's natural unit is the device and the task; NSO's is the end-to-end service across many devices.
3. Rollback semantics. Ansible rollback is something you design and handle; NSO's transactional model gives you all-or-nothing rollback by default.

Where each fits — and how they work together

In a well-designed practice the split is natural:

• Reach for Ansible for config automation, device onboarding, compliance remediation, ad-hoc operational tasks, and orchestrating steps across adjacent systems.
• Reach for NSO for complex, multi-vendor, transactional services where intent, consistency and rollback across the whole network are the requirement.

And they cooperate. NSO can own the service layer while Ansible handles tasks outside NSO's service models — or drives adjacent systems NSO doesn't manage. Both, critically, should draw their inputs from the same source of truth, so intent is consistent no matter which engine executes it.

How we approach it at TAMAKUN

We don't lead with a tool — we lead with the shape of the automation. We use NSO where model-driven, transactional service orchestration earns its keep, Ansible where task and config automation is the faster, simpler fit, and we bind both to the source of truth so intent stays consistent end-to-end. The result isn't "an NSO shop" or "an Ansible shop" — it's an automation practice that uses each tool for what it does best.