There are two approaches to the next steps in automation that we will make in the near future. One of revolution or one of evolution. Let’s look at each of these and lay out why evolving what you have today is a much more rational approach, in my opinion.
Revolution:
1.
an overthrow or repudiation and the thorough replacement of an established government of political network automation system by the operator people governed.
First of all, I did take some liberties with the definition of revolution above, but clearly this is how a lot of people are looking at network automation these days. Talk of revolutionary changes to how you manage the network can easily be found in most places. There are a few issues with trying to take a revolutionary approach to just about anything, but this is especially true when you are talking about a working network, with live customers dependent on its stable and continuous function, that has 10-15+ years of operational baggage involved in maintaining it.
Among these issues are:
- It is extremely disruptive to your staff
- Confusion – “What do I do to change this config again?”
- Resistance – “We have always done it this way and it worked, why did we change? This is stupid!”
- Pushback & Lack of Buy In – “I’m just going to go outside the system and change it via CLI!”
- It can be disruptive to your customers as well – especially if there are any gaps in testing that result in outages
- It takes a long time – complete “rip & replace” of existing tools is a multi-year, sometimes never ending, project
- It costs a LOT of money, in addition to the human costs mentioned
Evolution:
1.
any process of formation or growth; development
2.
a product of such development; something evolved
3.
Biology. change in the gene pool of a population from generation to generation by such processes as mutation, natural selection, and genetic drift
The evolutionary approach considers the fact that there are practices you have in place today that have served you well (mostly) for the years you have been operating your network. These tools and practices are perfectly fine for the network activities you need to execute. Maybe you have more people than you really need, due to a lack of automated processes, or maybe you experience some confusion on when to use which tool for which task, but for the most part your operational approach works…it just doesn’t scale or is too expensive to maintain.
A rational approach is to somehow consolidate those existing tools and processes under an automation platform that rationalizes the existing tools and provides a common interface and workflow. On some level this will appear that you replaced those systems because many of them will be abstracted away from the user’s view. This approach is not to replace everything, at least not on day one…or 100, etc. A key benefit of abstracting the interfaces to the existing tools is that it gives you the ability to change those tools, eliminate a few (as possible), but do so in a gradual manner to minimize cost and confusion.
To do so requires an analysis of your current toolsets and processes. You must identify those tools that have usable APIs (or APIs AT ALL , in some cases), and are, therefore, aligned with this approach. Those tools that are out of alignment should be further analyzed to see if their function can be consolidated into one of the compliant tools, or if a new tool should be introduced. In concert with this analysis areas should be identified that are gaps and have no tool whatsoever to fill them.
The result of this analysis should be three-fold:
- A list of tools that will be integrated with the automation platform
- A list of tools to be decommissioned
- A list of gaps that must be filled
The next step is to determine a plan for filling the gaps. Your should first identify tools that other organizations may have that you can leverage to fill gaps. In other cases open source tools such as Ansible, Puppet, Chef, etc will be able to assist here without the need to involve a vendor. This doesn’t mean you don’t involve outside expertise to conduct all of the above; it just means it may not be necessary in all cases.
I am going to pause here and point out that nothing in this process so far has involved having to buy any software, hardware, or services. This is a necessary task that you could dedicate 3 or 4 people to doing and not incur any costs outside of those resources. I will repeat that this is a completely necessary, foundational task to everything you will want to do in the future as you automate your network. No shortcuts.
The choice of an automation platform becomes pretty important next. You must pick a platform that can consume the APIs of all identified systems and present a unified GUI, with workflow, and pre-built, customizable applications. You must also be able to create your own applications using the platform and its exposed capabilities.
Try to stay away from platforms that want to replicate all of the data from your existing tools. That is old-school OSS thinking, and will get you in trouble with how efficient you need your network automation to be.
You don’t have to immediately move to a model-based approach to automation, but you MUST pick a platform that is capable of both model-based and non-model-based operation. You should also be careful that you don’t pick a platform that is purely intended to manage physical, or virtual, networks. The future of automation is a single platform managing a group of controllers and orchestrators that manage both physical and virtual. You must make sure you place yourself on the path to convergence here.
So, analysis of current tools and processes is complete. You have also picked a platform for intelligent automation. Only now can you begin to logically and rationally put in place automation practices that will last through the convergence of virtual networks with your existing physical networks. I truly believe this is the best path to lasting, long-term, intelligent automation.
Of course, there is a TON of detail I did not go into with how to complete each of those steps, and how to determine if a tool is compliant with this approach or not. Feel free to Contact Us to learn more about how we can assist in this effort, even if it is just education and guidance, and how Itential Network Automation can fill the role of the platform to meet the requirements listed…and more.
