One of the challenges traditional networking engineers face when starting their network automation journey is the “build or buy” decision: should I use a plethora of small open-source or commercial tools and components and build my own solution, or should I buy a humongous platform from a reassuringly-expensive $vendor.
Most of us were used to buying platforms ranging from CiscoWorks to HP OpenView (oops, Business Technology Optimization Software) or now Cisco’s NSO, so it’s natural that we’re trying to map this confusing new world into old patterns, leading to interesting discussions like the one I had during one of my workshops:
Q: Is Ansible an inventory tool?
A: Well, Ansible does need inventory of managed devices to do its work, and you can use it to collect information on modules, line cards, software releases, or serial numbers of managed devices. However, while I’m sure it would be possible to do a network discovery with Ansible, I wouldn’t. There must be better tools out there for that job.
Q: So is Ansible a configuration management tool?
A: You can definitely use Ansible to collect configurations from managed devices, but most people prefer RANCID as it supports more platforms. Furthermore, neither RANCID nor Ansible will provide a version control system; you could use SVN or Git for that.
Q: So where would I use Ansible?
A: You could use Ansible whenever there’s something that needs to be executed in parallel on numerous devices. That could be software upgrade, configuration change, collecting of inventory data, troubleshooting...
Q: Didn’t you just say Ansible isn’t an inventory or configuration management tool?
After a while I finally got the right analogy to explain the difference:
Network automation tools that the Build-It people (aka Network Toolsmiths) talk about are like Lego bricks. You can use them in a large variety of scenarios, but like every good Lego Master Builder you have to understand where and when to use individual bricks to get the job done. You can build almost anything with them, but it does require a significant amount of integration work and occasional programming to make the bricks nobody produced yet.
If you want to be in the Build-It camp (and I would strongly recommend you to spend some time there), you’ll find a great overview of network automation components in the Network Automation Tools webinar, and if you feel you need some help putting them together we’ll do just that in the Building Network Automation Solutions online course.
Traditional $vendor platforms are like a Lego DeathStar built and glued together by Lord Business. It looks great (even more so in polished PowerPoint), but you can’t dismantle it and build a Millenial Falcon out of its components.
Which one is better? There’s no right answer - as always, it depends, this time mostly on where you want to spend the money: on paying vendor engineers (after paying their sales and marketing teams) or your own engineers. It also depends on your size and budget - small organizations prefer to build things (because they don’t have the budget to buy the $platforms) as do some large organizations (because it’s cheaper to build than to buy zillion of licenses), resulting in another U-curve.
Finally, if you plan to have an argument with your boss, it’s worth noting that Gartner started recommending investing in premium people instead of premium products and I’m already looking forward to a discussion with Andrew Lerner and Simon Richard on this topic during the Spring 2017 Building the Next-Generation Data Center course.