As we have discussed already, Ansible code is highly portable. In the world of network automation, this is extremely valuable. To start with, it means that you could roll out a configuration change on a development network (or simulator) and test it, and then be able to roll out exactly the same code against a different inventory (for example, a production one) once the configuration has been deemed to have been tested successfully.

The benefits don't stop there, however. Historically, in the event of issues with a software upgrade or configuration change, the challenge of the network engineer was to engage the vendor for support and assistance successfully. This required sending sufficient detail to the vendor to enable them to at least understand the problem, and most likely want to reproduce it (especially in the case of firmware issues). When the configuration for a network is defined in Ansible, the playbooks themselves can be sent to the vendor to enable them to quickly and accurately understand the network topology and diagnose the issue. In fact, I has come across cases where network vendors are now starting to insist on Ansible playbooks with network configuration when a support ticket is raised because it empowers them to resolve the issue faster than ever before.

Effective use of ansible-vault ensures that sensitive data is kept out of the main playbooks and, hence, can easily be removed before being sent to a third party (and even if it was accidentally, it wouldn't be readable).