By Mike Haugh, VP of Product Marketing
In the tech center of Denver, Autocon 0, the inaugural event of the Network Automation Forum (NAF), unfolded as a thoughtful exploration of the challenges surrounding network automation. Industry veterans Chris Grunderman and Scott Robohn set the stage for introspection, seeking to understand the reasons behind the comparatively slow adoption of network automation.
Drawing on my extensive 25-year journey through the landscapes of service providers, enterprises and startups, I approached Autocon 0 with a sense of anticipation. With the narrow focus of the event, I was surprised by the turnout of over 400 like-minded end-users, vendors and experts converging to celebrate and revolutionize network automation. There was a unique buzz in the air being at the first event as industry legends such as John Willis, Kireeti Kopella, Jeremy Schulman, Kirk Byers along with end users and vendors took the stage sharing their insights on the hurdles and opportunities in network automation.
The Focus on Network Automation:
As one presentation highlighted, there is a perfect storm brewing in the realm of network automation:
- Network infrastructure complexity escalating.
- A talent shift towards security, cloud, and AI, leaving fewer hands to tackle automation challenges.
- Networks are emerging as the lifeline for businesses, demanding a redefined approach to ensure agility along with performance and availability
Autocon 0 aimed to unravel the potential of network automation, steering it away from a mere side project or afterthought toward a transformative force.
Central Themes:
Key themes emerged throughout the discussions including comparing the gradual rise of the DevOps movement and highlighting the struggles of network engineers facing resource constraints and prioritization challenges.
The pre-event survey, along with data from most analyst firms shows that network automation is not well adopted, and many organizations perform most changes via manual CLI and automation efforts are mostly limited scripting. Many sessions identified a key problem is that organizations do not prioritize network automation and as a result, they have limited resources working on it and limited results.
Another significant theme is that most automation efforts are a subset of network engineers within organizations that take it upon themselves to develop skills and achieve limited success, yet their work is often not reviewed, shared, or even tested so they fail to move the needle within their organizations.
Exploring Tools and Approaches:
Speakers delved into a spectrum of tools and approaches, ranging from the pros and cons of open source, vendor solutions, Ansible playbooks, OpenConfig, digital twins, API integrations, containers, and self-built Python-based solutions.
There were inspirational stories of hero engineers who took on problems within their organizations, developed automated solutions, and helped to create transformational changes that delivered value to the business.
Examples of successful do-it-yourself (DIY) usually involved extensive efforts using Python programming (with many plugins and packages), a database/repo, task-level automation and workflow-level orchestration, agile development, integrated monitoring/feedback for closed-loop, and more.
Transitioning to Full-Blown Software Development:
A recurring call to action was the need for a fundamental shift from limited scripting to a comprehensive software development approach. Best practices, including code repositories, reusability, and adherence to a full CI/CD process, were emphasized. This is a very challenging shift for most organizations since it requires both network engineering and software development skill sets. Network engineers are often “keeping the lights on” reacting to operational issues while also performing required moves/adds/changes. Software development requires time to develop, test, deploy and maintain code. They are very roles historically both from the types of work along with how they are incentivized and managed. Management also needs to change to understand software development. Many presentations highlighted the challenges when going down this path:
- Trust must be built with automation, so this requires additional overhead to minimize risk when automating changes including code review, testing, using a digital twin, pre/post checks and others.
- Network automation must be closed loop. This should include the verification of of the change along with the monitoring of the operational state.
- Automation should be designed to be multi-vendor – if not, it will require re-writing or refactoring when the requirements expand.
- Automation also requires orchestration – the goal should be automating a use case, not a task. This expands the requirements to multiple domains and technologies, CLI and API.
- Automation should enable the definition of the intended state and then be able to implement changes in a declarative and idempotent manor to minimize risk and address various brownfield situations.
- Automation must be well documented, accessible to all users and implement secrets management along with role-based access controls.
- Automation must be scalable and meet expectations regarding performance – this typically requires serialized/parallel operations.
- Automation must provide extensive logging both when it works and when it doesn’t to identify exactly “who did what, when”.
Anticipating the Future:
A few presentations and panels looked toward the future, including Kireeti Kompella’s progression to “the self-driving network” and the analogy of the self-driving car which like the network will be human assisted but many useful features will come from integrating observability/monitoring and network automation. The use of AI/ML (AI Ops) was another theme with several presenters talking about and even showing how Chatbot interactions and predictive use cases are already becoming available from some vendors.
NAF – A Hub for Collaboration:
As Autocon 0 concluded, the NAF emerged as a community for collective innovation. The attendees, fueled by positivity and shared energy, pledged to propel the network automation revolution forward. There are no one-size-fits-all solutions, and unlikely that some “common data model” or single approach will win since the vendor community is not incentivized to unify the approach. However, putting pressure on network vendors to provide automation-friendly products including well-defined APIs will be a good step forward. I see NAF as a place where users, experts, vendors and more get together to share information and approaches to help accelerate the adoption of network automation.
Starting the Journey:
The imperative for organizations remained consistent:
- Seek executive sponsorship and allocate resources.
- Spend the required time on the use cases, requirements and design.
- Start small, learn, demonstrate value, and expand.
- Cultivate a culture of training, cross-training, and learning from each other’s victories and missteps.
Gluware – Your Catalyst for Change:
From my own experience, there is a broad spectrum of approaches and solutions for network automation. I have seen first-hand that transforming an organization from network engineers to programmers who can self-build enterprise-grade automation is a heavy lift. There are many challenges to overcome in regards to the training, documentation, testing, software maintenance and more that come with a full DIY approach. It is worth the effort to evaluate commercial offerings, like Gluware, that can accelerate the network automation journey while still providing flexibility for organization-specific use cases and integrations. Gluware has helped customers deliver value within weeks and months not years.
Why Customers Select Gluware:
Several presenters at the conference said that they would rather buy solutions than build them. One used the analogy that no one would (or should build) their own self-driving car. Many Gluware customers have attempted to build their own before coming back to buy what Gluware provides and limit building to value added differentiation and customization. Here are some of the top reasons customers choose to buy vs build:
- They manage large brownfield multi-vendor networks – above a few hundred devices automation quickly becomes a necessity. With multiple vendors and typically many platforms from each vendor, automation can get exponentially harder. Gluware scales to tens of thousands of devices, providing a distributed architecture and has support for 40+ vendor OSes and API integrations out of the box.
- They have pressing use case and have not had success or do not want to build it internally. Gluware provides a suite of applications covering the most common automation use cases delivering value quickly, typically within weeks or months. This includes network discovery and inventory, troubleshooting and assessment, config drift and audit, topology and site documentation, configuration management and process automation. These are no-code applications designed for network engineers.
- They have organizational unique requirements that require customization. Gluware is highly customizable within the pre-built app suite as well as via the Gluware IDE, Gluware Lab, that provides data-modeling capabilities, business logic for a deep level of customization and 3rd party integrations. Gluware’s configuration management, Config Model Editor app, provides automation of any configuration the user brings from typical globals to sophisticated EVPN-VXLAN designs.
- They have requirements for process automation and 3rd party integrations. Gluware’s Network RPA app provides drag and drop workflow building to simplify process automation. In addition, there are pre-built third-party integrations provided by Gluware directly and through integration with StackStorm. Examples are integrations with ITSMs including ServiceNow, monitoring including Kentik, Sources of Truth, running Ansible playbooks, messaging like Slack and hundreds more.
Reflecting on Autocon 0, the journey ahead promises evolution rather than revolution, with NAF serving as a community to help those navigating the complex landscape of network automation.
About the Author
Michael Haugh brings over twenty-five years of experience and leads Product Marketing at Gluware. Prior to Gluware, Michael was VP of Product Management at ClearPath Networks. He has previously held roles in System Engineering, Product Management, and Marketing at Ixia and Spirent. Michael also worked at IBM Global Services and AT&T in Network Operations, Network Engineering and as a Design Engineer. Michael, Cisco CCIE #4334, AWS Certified Cloud Practitioner, and holds a B.S. in Engineering from Southern Illinois University.
