The 2020 results of the NetDevOps Survey are out! This was the third time the survey was conducted and was targeted to the network automation community. But first, a huge shout out to the team that led this effort again (Damien Garros and Francois Caen). The survey was 100% community-driven, and I thank them for allowing me to be a part of the team, and to provide feedback to existing and new questions.
This survey is a good representation of how network operators and network engineers are utilizing automation to get their jobs done, but largely without management buy-in or a proactive automation strategy. This blog is largely my hot take on the results, as seen through the lens of my history at Red Hat as an Ansible Product Manager helping to get network automation as an official commercial use case off the ground. I’m going to compare and contrast the survey questions and results between the most recent NetDevOps survey and the Enterprise Management Associates (EMA) Enterprise Network Automation for 2020 and Beyond results that Red Hat sponsored back in 2019.
Here are the main ideas I gleaned:
- Ansible continues to be the de-facto network (and more) automation language.
Because “Ansible is YAML” it’s extremely accessible for beginners to automate their networks, while providing a gateway to more advanced DevOps workflows and CI/CD integrations. Ansible was originally created because the barrier to entry for programming Python code was too high while scaling to large distributed teams. They’d say, “But Ansible is so slow! Just use Python!” That’s totally valid, but the goals for Ansible (which actually is an application written in Python) are to abstract away programming complexity to gain simplicity. There will always be trade-offs, but we believe automating large sets of diverse endpoints (network, cloud, Windows, security, etc.), by large sets of teams need an enterprise automation solution to operationalize and scale their entire IT organization. That being said, enterprises choose Ansible (the language) because it does more than automate networks, and does more than just configuration management by means of Red Hat Ansible Automation Platform. Regardless, it’s impressive that roughly 90% of the NetDevOps respondents have some interest in Ansible automating their networks. - Automation is still largely a manual activity, not part of the whole process.
Manual automation sounds weird right? But that’s what the network automation community is largely doing today. That is, over 80% of the NetDevOps respondents are using automation to push configurations, but also 88% allow for ad-hoc changes via command-line interface (CLI) after the fact (only to have to re-push again and again). Almost 60% of the NetDevOps respondents are not leveraging automation to auto-remediate or validate changes that are made on behalf of network operation tasks. This means that automation is still used when it’s convenient to the operator, but not as part of an overall holistic automation strategy. Those with automation strategies via the EMA survey show only 14% of respondents are automating with ad-hoc manual and reactive automation of specific network management tasks [Figure 12]. - Individuals are continuing to automate without leadership buy-in or strategy. Surveys are a fantastic way to gauge user adoption, but it’s good to know exactly who is responding and what their goals, motivations, and resources available are. The good news here is that Ansible is the top choice for both community and enterprise network automation use cases, but the bad news is that top-level leadership and strategy often dictates the amount of investment (time, money, training) to meeting long-term automation goals. The NetDevOps survey shows that the majority of respondents are not getting the tools they need to automate their network appropriately, nor are they being sponsored for proactive network automation initiatives. They need time to learn, formal training, additional budget, and a top-level strategy to execute against a formal automation program. On the other hand, in the EMA survey, 83% of the respondents claim that they are devoting somewhat or very significant training to existing personnel [Figure 21]. This demonstrates the acknowledgement of their need for a long-term commitment to skills development, so network engineers can spend less time “firefighting.”
- Network source of truth, version control, and CI/CD are the next frontier.
As seen as an evolving requirement in enterprise network automation projects, a new set of questions were added around the network source of truth to the NetDevOps survey. Only about 35% of the NetDevOps respondents have an authoritative source of truth. We asked a similar question of enterprise network automation professionals via the EMA survey and 89% of the respondents [Figure 14] have one or more authoritative data repositories for different classes of information. I expect the concept of a network source of truth will continue to be a large part of all network automation environments going forward.It’s great to see version control is keeping track of network configuration changes, which lends perfectly to the strategy the Ansible Network Engineering team has been doing around Ansible network resource modules. The Ansible network resource modules align well with a network automation engineer’s expectations for managing configuration as code. I’m really looking forward to the forthcoming BGP and static route resource modules for Cisco IOS, IOS XR, NX-OS, Juniper Junos, and VyOS.
Less than 7% of the NetDevOps respondents are automating software qualification, which is an important activity for ensuring that changes to the network are tested and validated prior to pushing live to production. This is also an integral part of established software engineering principles (as well as CI/CD) and I’d expect this activity to build momentum in the near future.
Conclusion
Regardless if you are automating to get your job done or automating towards an enterprise automation strategy, the components of a network automation solution almost always have some amount of Ansible in it. Getting started with Ansible in the community has made it the de-facto network automation language, but when enterprises are ready to operationalize and scale Ansible, Red Hat Ansible Automation Platform is a recognized leader. Thank you again to the volunteer team that administered the NetDevOps 2020 Survey, and hope to help with the next one soon!
- Are you new to Ansible Network Automation? Check out our Network Getting Started Guide.
- Download our free e-book: Network Automation for Everyone
- Interested in a trial of the Red Hat Ansible Automation Platform? Sign up automatically at red.ht/try_ansible.
Originally posted on Ansible Blog
Author: