Welcome to a new series where we interview Ansible experts on IT automation and ask them to share their direct experiences building automation solutions, as well as any insights they have regarding the state of the industry.
In this post, I’ve asked Peter Sprygada and Eric McLeroy five questions about network automation.
Peter Sprygada is a Senior Principal Engineer at Ansible by Red Hat where he brings over 20 years experience building and operating global network infrastructures. He holds two patents in network configuration automation and currently leads the Ansible network engineering team that focuses on building and integrating network automation capabilities into Ansible. Formerly Peter was responsible for building and leading the Arista EOS+ Extensibility Engineering team where he focused on applying DevOps methodologies to enhancing network operations. Prior to that, he held senior network engineering and operations roles at various organizations including Cisco. You can follow him on twitter at @privateip.
Eric McLeroy is a Senior Solutions Architect for Ansible by Red Hat focused on networking use cases. Eric has over 10 years in networking in large scale environments working with a large variety of systems from routers, switches, load balancers, etc. He holds multiple industry certifications and several degrees within the field of networking.
1. What are the most important first steps in a team's journey toward automating a networking environment?
Peter: When organizations first start their journey towards automation there are a few key first steps. First, network automation needs to be way of life that is infused into the operations team. There needs to be complete buy in across the board. Second, define small incremental wins that can easily be achieved yet address common pain points. Don’t try to infuse an entire automation strategy on day one. Finally, define metrics to track successes.
Eric: I feel the most important first steps toward automating your network environment is picking the right tool and having your network staff on board for the change in mentality. Without the willingness to change you are stuck in the old way of doing the work by hand. That is where Ansible comes in as it allows the users to utilize the knowledge they already have on the networking side and with a little bit of code and formatting from Ansible they are able to start automating from day one.
2. What are the most common pitfalls for organizations automating a networking environment?
Peter: The single most common pitfall that most organizations run into with regards to automating network environments is to not embrace it. Fight the urge to fall back to manual process... otherwise network automation will never take hold if it isn’t given due priority. The second common pitfall is to try to do too much too fast. Network automation needs to be consumable in bite-sized chunks. Trying to define a holistic strategy on day one is doomed before it starts. Focus on solving small tactical problems that are common everyday struggles. Learn and re-evaluate the approach as necessary.
Eric: Some of the most common pitfalls that customers fall into that I have seen is utilizing source control, dynamic inventory vs manual inventory, and political landscape. Most networking professionals do not normally save their MOPS (Method of Procedures) to version control but to their desktop. They have to account for the need to have a central repository such as GitLab or GitHub that will allow them to easily update their playbooks and collaborate together. In a large amount of cases I have seen that the networking teams do not have a single source of inventory. This brings in the question do they create a manual inventory that can grow significantly and use Ansible as the single source of truth or try to bring in all of the CMDB solutions into different inventories. The political nature of the networking teams that are intertwined with compliance, auditing, security, etc. causes a tough change in mentality as well.
3. Are there any common misconceptions about network automation with Ansible these days?
Peter: It's not magic and it cannot do anything that it isn’t explicitly told to do. Ansible is all about taking common everyday tasks and making them repeatable and scalable. Ansible doesn’t have the knowledge to run your network; it’s a tool to help you run your network more efficiently.
Eric: The primary misconceptions are that you have to be a coder to use Ansible, that I will automate myself out of a job, and whether or not open source is the right step for my company. The great thing about Ansible for networking is that you are able to apply your current knowledge of your working systems and use Ansible to automate them without having to learn something like python that can be daunting for a network engineer that has never coded anything. With automation you are freeing yourself up from the mundane tasks that you have to do over and over and open yourself up for additional challenges that will provide benefit not only to you as a professional but to your company.The open source aspect allows the level of growth that we are seeing in networking modules as the community provides feedback directly and allows for more control over your own destiny as you are also able to create your own modules as needed.
4. Why has Ansible become so successful for networking use cases in such a short amount of time?
Peter: In a word, simplicity. Ansible strives to perform its activities and then get out of the way. This allows operations and engineering teams to tackle difficult network problems and then deploy them with ease. Also, Ansible works with everything. Its architecture is well suited to be equally effective across the myriad of IT disciplines. Lessons learned and best practices implemented on one team can be equally shared and leveraged across all teams.
Eric: There are many reasons why Ansible is succeeding in networking and those can be attributed to the community, vendor support, and the ease of use of Ansible within the networking space. The community is driving Ansible every day with more and more module adds along with feedback and new ideas. The help from vendors creating modules for their own equipment is another driving factor the strength of Ansible in the networking environment is so strong that customers are demanding modules for Ansible support. Again it all comes back to the ability to use what you know which can be a comfort for those trying to branch out to something new. The simple nature of Ansible drives the ability for the networking teams to step in and really start to see changes from day one with the simplicity of Ansible.
5. What do you think the future holds for networking and how do you think automation will fit in? Five years? Ten years?
Peter: Networking will continue to become more and more of an application with less dependency on an aggregated hardware / software stack. Much in the same way L2/L3 lines blurred almost to the point of being indistinguishable, traditional networking and host networking will do much of the same. As this happens, automation will become the new “cli” for network implementations for both tactical and strategic operational management.
Eric: I think the future of networking requires the shift to automation. Without the ability to automatically change and develop more advanced networks that encompass not only legacy but cloud networking at scale will be unmanageable by hand. I can see fully automated networking systems built into the approval workflows of these systems to be common practice in the next five years. I feel that with automation in the next ten years you will see self healing networks that will be able to adapt and change with the environment and failures that come along with large scale build outs. After that who knows what could happen when we're talking automation and Ansible specifically there is no limit to what we can do together.
Read about building, managing and scaling network automation with Ansible.
Register for an upcoming Ask an Expert webinar to join an open discussion with Ansible staff.
If you have any comments or ideas for future interviews, feel free to tweet at @Ansible.