Network Automation: Commercial or Open Source?

In my last post, Automation Tools for Different Tasks, I discussed the differences in tasks that drive tool selection. But the array of options is confusing, with the question of whether to buy an expensive commercial product or build your own open-source solution being a big consideration. Is it better to buy an expensive commercial product or build your own solution around open source tools? What are the tradeoffs?

 

When doing your analysis, use a common operational framework – like my personal favorite, a model incorporating people, process, and technology (PPT) to drive action.

 

 

People are the most important component of the framework in that smart network engineers can overcome deficiencies in process and technology. They can determine which technology to implement, how best to deploy it (process), and which technology and processes aren’t effective in a situation or for a task.

 

Next, you’ll have to determine who will own the tool and what skills they have. You’ll need multiple tool owners so that your organization isn’t handicapped when someone is on vacation, takes sick leave, or resigns. The skills to implement an open-source solution will be quite different from those required to deploy a commercial product. Both approaches necessitate learning new paradigms, but the details and skills are very different.

 

Well-defined processes make tasks easily repeatable, with consistent results guaranteed. If you’ve selected the right people for the job, they’ll be able to create great processes that turn marginal tools into amazing automation systems.

 

You’ll quickly appreciate a network based on standard building-block designs that make it easier to create processes that apply to more of the infrastructure. Leading organizations realize this and don’t take shortcuts in network design and implementation. Fewer design variations result in fewer and simpler processes. This, in turn, reduces the amount of time your staff must put toward creating and maintaining them.

 

Tools are like power amplifiers for the networking team - don’t expect one to be enough. Research tool performance for the tasks you need to automate. A system that can’t handle many devices in parallel might be unable to finish its work within your change window constraints. Also, look for systems in which network operations are capable of being daisy-chained. Be sure to include tools that can validate configuration changes to confirm they resulted in the desired operational state.

 

Once you’ve evaluated your staff’s capabilities and the types of tasks (processes) that need implementing, and this will require additional evaluation criteria, it’s time to decide between commercial and open source.

 

Don’t try to do too much at once. Begin with an overall game plan, pick a few simple tasks to start with, select a product, and conduct a proof-of-concept (PoC) test. You can’t do this on more than one product or task at a time.

 

What is your implementation time? If your organization likes to see results quickly, you may benefit from choosing a commercial product, simply because of the time it takes to create or adapt open-source tools. On the other hand, if your organization is very cautious about network automation, a slow-roll process using open-source tools may be the right solution.

 

Commercial configuration management tools are widely available, including vendor-specific options such as Cisco’s DNA-Center and Juniper’s Contrail. Cisco’s Network Services Orchestrator can handle multivendor networks, as can systems from companies like Gluware and Itential. These allow your existing network engineers to work with configuration snippets that they already know. Unimax has a great reputation for handling unified communications MACD functions. Many of these tools are easily integrated into existing processes and don’t require extensive re-education of the network staff. A PoC implementation with specific, measurable goals can help you evaluate potential products in a real-world scenario. Many products can achieve significant results within a few weeks of deployment.

 

You shouldn’t be put off by the cost of commercial products. Yes, they can seem expensive. But look at the cost of staff time to develop comparable systems using open-source tools. Two good developers will likely cost in excess of $300,000 per year for salary and benefits. You can buy a lot of commercial products for that much money per year.

 

A downside to commercial products is that you get what they produce. Include diagnostics and troubleshooting in the PoC so that you know what’s involved. Try to get a sense of whether your vendors are focused on releasing the next big feature instead of making the last feature truly useful.

 

Open-source tools have proliferated in the past few years and it’s hard to avoid the mention of Ansible, Salt, NAPALM, pyATS, and Nornir. These tools provide the ultimate flexibility in functionality. They are applicable to any of the network automation tasks but are ideally suited for network validation and network troubleshooting tasks. Do note that you’ll need a source-of-truth database to drive the automation processes that determine whether the network is configured and functioning as you desire.

 

Expect a long delay between starting an open source-based automation project and achieving the result. Network teams seldom have software development expertise, so consider your staffing requirements, too. An alternative to in-house staffing is to use a consulting organization like networktoCode.com or Cypress Consulting to build solutions from open-source tools. They may have packages that can significantly reduce your time to deployment. Keep in mind, that some vendors have consulting teams that can aid in building custom solutions.