Network Automation: Lego Bricks and Death Stars

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.

We’ll cover this use case in Week 2 (Easy Wins) of Building Network Automation Solutions online course.

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.

4 comments:

  1. I believe in investing in "premium people".

    However...

    If "Premium People" is your strategy, I hope you've developed a core competency around finding, attracting, and retaining those people. Frankly its harder to find and keep premium people than it is to choose and install pretty-decent $vendor_product.

    The advantages $vendor_product have are their relatively consistent quality and their infinite scale. For most businesses, that's an easier and more sensible trajectory than trying to gather up all the unicorns and have them build the rainbow palace.
    Replies
    1. Easier is not always better in the long run :)
  2. Legoset made on the Deathstar or a Deathstar made of Lego? :-)

    https://github.com/ios-xr/iosxr-ansible
  3. +1 to Jason comment.

    It is great to work with "premium people". I had a pleasure to work with such individuals. I like this kind of work. But on the other hand, people management is usually much harder than management of technologies. Especially commoditized technologies. That's the main reason for generalization, abstraction, virtualization, automation which leads to commoditization and usage simplification. Of course, all this leads to bigger complexity under the cover therefore if customer does not have competency for it then he has just two options.

    1/ investment into vendor's products developed and supported by their "premium people" or
    2/ buy IT products as a services. That's actually what cloud services means for me.

    "Premium people" is limited resource thus these people will work mainly for vendors or service providers.

    Therefore non-IT companies, in my humble opinion, will have to rely on technology vendors or service providers. Investment into "premium people" must be calculated in TCO and ROI and only ROI can prove if such investment makes sense.

    Just my $0.02.
Add comment
Sidebar