The question gets asked as though one of them wins. It is the wrong question, and the fact that it keeps being asked usually signals that the estate has not yet separated two genuinely different jobs.
Two different problems
Playbook automation and model-driven orchestration are not competing answers to one problem. They are answers to two problems that happen to both involve changing device configuration.
Task automation asks: how do I perform this operation across many devices reliably and repeatably? Upgrade the firmware. Push the new NTP servers. Collect the state of every BGP session. The unit of work is a task, the scope is a set of devices, and the model is imperative: do this, then this, then this.
Service orchestration asks: how do I deliver, modify and withdraw a service that spans multiple devices and domains, as a single transaction, while keeping a durable model of what that service is? Turn up a Layer 3 VPN across four PEs. Change its bandwidth. Delete it cleanly. The unit of work is a service, the scope is whatever devices that service touches, and the model is declarative: this is the intended state, make it so.
The three capabilities that mark the boundary
Transactionality
A service change that succeeds on three devices and fails on the fourth has left the network in a state that matches no intent. Model-driven orchestration handles this with a transaction that either commits everywhere or rolls back everywhere, and it can do so because it holds a model of both the intended and the actual device configuration.
Playbook automation can approximate this with careful error handling and hand-written rollback tasks. It works until the failure mode is one you did not anticipate, which is the failure mode that matters.
Service lifecycle and deletion
Creating a service is the easy half. Removing it cleanly, three years later, when the estate has changed around it, is the hard half. An orchestrator that maintains the mapping from service instance to the specific configuration it created can withdraw exactly that configuration and nothing else.
An imperative approach leaves residue. Everyone who has run a large network has found orphaned configuration belonging to a service that was decommissioned long ago, that nobody will remove because nobody is certain what it does.
Reconciliation against reality
Networks drift. Someone makes an emergency change at two in the morning. A model-driven orchestrator holds a view of what each device should look like and can report the difference, then either restore intent or absorb the change deliberately. Imperative automation re-runs and hopes idempotence covers it, which it does for the cases the author thought about.
The test
If you need to answer "what does this service consist of, right now, across every device it touches, and can I remove it without breaking anything else", you need orchestration. If you need to answer "did this operation run successfully on all two hundred devices", you need task automation. Most estates need both.
How they work together
In a well-organised stack the division is clean:
- The source of truth holds the data. Neither tool owns inventory.
- The orchestrator owns services with a lifecycle: anything created, modified and withdrawn as a unit, spanning devices, where partial application is unacceptable.
- Playbook automation owns fleet operations: upgrades, compliance sweeps, state collection, bulk day-two changes, and the operational glue around the orchestrator such as pre-checks, evidence capture and post-validation.
- The workflow layer sequences both, handles approvals, and writes back to service management.
A common and effective pattern is playbook automation calling the orchestrator's API rather than touching devices directly for service changes, while retaining direct device access for the operational tasks that are genuinely out of scope for a service model.
When you do not need orchestration
Worth saying plainly, because the industry rarely does. Model-driven orchestration carries real cost: service models must be written and maintained, device models must be kept current, and the skills are specialised and scarce. That investment pays back when services are numerous, repetitive, multi-device and frequently changed.
An estate that turns up a handful of services a year, each slightly different, will spend more on modelling than it saves. Such an estate should do excellent task automation against a solid source of truth and revisit orchestration when the service volume justifies it.
Buying an orchestration platform before you have services worth modelling is the most expensive way to discover this.
The sequencing that holds
- Source of truth first. Both tools become more capable and less brittle once the data is authoritative.
- Task automation next. Fast payback, broad applicability, and it builds the engineering discipline the later layers depend on.
- Orchestration when service volume and repetition justify the modelling investment, starting with the single highest-volume service type.
- Workflow and approval integration throughout, so that automation is governed rather than merely available.
Teams that follow this order rarely ask which tool wins. The answer becomes obvious once the work is separated into the two jobs it always was.