Netfortius made an interesting comment to my Ansible playbook as a bash script blog post:

Ivan - aren't we now moving the "CLI"[-like] approach, upstream (the one we are just trying to depart, via the more structured and robust approach of RESTAPI).

As I explained several times, I don’t know where the we must get rid of CLI ideas are coming from; the CLI is root of all evil mantra is just hype generated by startups selling alternative approaches (the best part: one of them was actually demonstrating their product using CLI).

Have to admit though that there’s a huge difference between the scriptability of typical Linux CLI and the arcane stuff you get on network devices. Just because they look similar doesn’t mean that they are. Speaking of differences: the network device CLI tends to be way more consistent than UNIX or Linux CLI were before Cumulus Networks invested time into writing NCLU.

Regardless of the acronym layers, what we really want to do is to get our network infrastructure automated. You could decide to buy a monolithic $vendor product (because that worked so well in the past), or an extensible platform (Cisco NSO is a great example… but keep in mind that SAP is also a highly-extensible platform), or build your toolchain from smaller components (the UNIX way).

In any case, as I explained in the last session of the autumn 2017 network automation online course, there are several ways your automation solution will be consumed:

• You need a GUI (or something very close to it) for a casual user;
• You need an API for upstream software (for example an umbrella orchestration system) consuming your solution. The upstream API could be as simple as call this bash script using that username.
• You need CLI for power users who have to get the job done fast.

Making Ansible playbooks easily consumable by wrapping them into bash/Python/Perl/whatever scripts, making them into executable scripts, invoking them with inv or embedding them into a bigger Python solution reduces the friction for the CLI users and might prevent fat-fingers mistakes that occasionally bring down whole data centers.

To summarize – as with any other software project a network automation architect must:

• Figure out what needs to be done;
• Find out who the users will be, what their expectations are, and what the best UX (User Experience) is for each type of users (aka persona);
• Find the best tool(s) or toolchain for the job;

Then it’s up to the software developers to:

• Get the core job done;
• Implement all the necessary UI bindings.

Want to go down this journey? Hundreds of your peers already did by joining the Building Network Automation Solutions online course.