This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.
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.
Commercial vs Open Source
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.
As with all things in networking, the right answer for your organization depends on several factors.
• What is your staff capable of handling? Do you have software developers available or can you hire contractors?
• What tasks do you need to accomplish (i.e., what are your goals)? Complex tasks will require more time to implement. Start with simple tasks and work up to the more complex.
• How consistent is your current network? (hardware, operating systems, configurations)
• What is the timeframe in which you need to show results?
• Have you already adopted network automation and want to progress further?
• Do your organization’s executives support use of network automation?
Network automation covers a wide range of activities, including:
• Device location, troubleshooting data collection, and other read-only operational tasks
• Comparing network configuration against a source-of-truth database; this can include network operation verification, which is often read-only
• Tracking configuration drift
• Handling simple configuration changes like NTP, SNMP, etc., as well as complex configuration changes like route maps, QoS, ACLs, and MPLS
• Integrating configuration changes with operational verification
• Continuous integration and continuous deployment (CI/CD) processes
You must decide where your organization is on the continuum from read-only tasks to CI/CD in order to select the appropriate tool for the task at hand. Each tool/technology has different strengths and weaknesses. It pays to spend the time to understand your requirements and identify the best tools for your needs.