One of the most important aspects of the introductory part of my Building Network Automation Solutions online course is the question should I buy a solution or build my own?

I already described the arguments against buying a reassuringly-expensive single-blob-of-complexity solution from a $vendor, but what about using point tools?

In that case, my reasoning would be just the opposite: as long as the tools have well-defined edges and can interact with the outside world with an API (or text files in a directory) don’t even think about reinventing the wheel. Use whatever tools gets the job done, but retain the control of the overall solution architecture and the interfaces between components (more details in the excellent presentation Elisa Jasinska had in the automation online course).

The control of the overall architecture gives you the ability to replace individual tools with better ones or (worst case) your own solution if it turns out to be impossible to tweak the tool to meet your needs.

You should also consider these parameters (that I described in more details in the Planning Phase section of Building Cloud Infrastructure webinar – hat tip to Chris Young for reminding me to include them):

• How much will it cost me initially, which might skew you towards “build it” if you already have the internal resources that could get it done. Keep in mind the cost of “build it” option will almost always be underestimated, more so if your team has no experience in building this particular wheel (I know several service providers who wasted years trying to build their own OpenStack cloud from scratch);
• How much will it cost me over the lifetime of the project, where you have to guestimate the long-term support and maintenance costs. Yet again, try to keep the costs of “build it” option realistic;
• There’s the time-to-value factor that always skews towards “buy it”

Did I mention tweaking?

Don’t. Honestly, don’t. Use tools the way they were designed to be used (reading the documentation usually gives you the cluebat you need). You want to use a tool beyond what it was designed to be doing? Time to find another tool.

Sounds academic?

Let me give you two simple examples:

A while ago I wrote an Ansible playbook that grabs device configurations and pushes them into a Git repository. The only reason: I was too lazy to read RANCID (or Oxidized) documentation and deploy the proper tool for the job. Would I do that in a production environment? Of course not – developers of RANCID and Oxidized spent way too much time figuring out how to grab configurations from a gazillion of different devices and clean the configurations (remember ntp clock-period?).

Another example: I created a set of Ansible playbooks to test configuration compliance to illustrate how you could combine simple tests into a large test suite. It turns out there’s a better tool to get the job done: Gian Paolo Boarina discovered Netshot.

Got the idea? Every time you’re facing a challenge, spend some time looking for the tools before creating your own.

Next question: how much time should you spend looking? How about 37%?

Totally off-topic: the Algorithms to Live By book is awesome.

Speaking about wheels…

Finally, once you figure out that you can build something, you often get this urge to reinvent and rebuild every wheel you need. If that’s the case, follow this simple set of rules (for open-source wheels) that Nick Buraglio put together:

• If the wheel exists don't build another one;
• If the wheels aren't exactly the shape or size you need, augment the wheels and contribute your augmentations back for review and inclusion in the wheel inventory.
• If the wheels don't exist, build a wheel and share the plans for the wheel.

This blog post was initially sent to the subscribers of my SDN and Network Automation mailing list. Subscribe here.