From Scripts to Production
Real-World Network Automation Deployment Strategies
Based on insights from Network Automation Forum (NAF) community members
Network engineers are excellent at writing automation scripts—whether they're checking port utilization, running show commands across devices, or managing ServiceNow integrations. But there's a massive gap between having a working script on your laptop and deploying something that non-programmers can safely use in production. This challenge sparked an engaging discussion in the Network Automation Forum community, revealing practical strategies that engineers are actually using in the field.
The Challenge: Bridging the Gap
The fundamental question posed by community member Adam Angell resonates with many network engineers: "What have people done in real production to allow non-programmers to run the code?" This isn't just about technical implementation—it's about creating sustainable, secure, and user-friendly interfaces for complex network operations.
The examples Angell shared highlight typical automation use cases:
Port utilization reporting across switches
Device command execution with data retrieval
Ansible playbooks for ServiceNow change management
Multi-platform device verification (DNAC, NetBox, ServiceNow, Orion)
These scenarios represent the bread-and-butter of network automation, but they also illustrate the complexity of making automation accessible to broader teams.
Web-Based Frontends
The most prominent theme in the community discussion was the adoption of web-based user interfaces, particularly Streamlit. Multiple experienced practitioners highlighted this Python framework as a game-changer for network automation deployment.
The Streamlit Approach
Community member "Steinzi" outlined a practical five-step process:
Create a working CLI Python application
Put on your "vibe coder hat" (their words, not ours!)
Use AI assistance to convert the CLI app to Streamlit
Debug and refine the interface
Deploy to users
This approach appeals to network engineers because it doesn't require deep web development skills while providing professional-looking interfaces.
Real-World Implementation Insights
Consultant Claudia de Luna shared valuable deployment patterns her team uses:
Hybrid deployment models: Both centralized servers and local GUI deployments depending on client network constraints
Input validation: Extensive use of dropdown menus and validation to minimize user errors
Fail-fast philosophy: Aborting operations at the first sign of unexpected conditions
The consulting perspective is particularly valuable because it reflects the reality of working across diverse client environments with varying security constraints and infrastructure limitations.
Authentication and Security
The discussion revealed several practical approaches to handling authentication in network automation tools:
Application Authentication
Streamlit's built-in authentication features (st.login, st.user)
NGINX as a reverse proxy for authentication brokering
Local authentication fallbacks when AD integration isn't available
Device Access Authentication
TACACS+ integration with service accounts where possible
User credential input when SSO isn't available (with acknowledgment of the security implications)
Maintaining traceability in underlying systems
As one community member noted: "Sometimes you just got to do some nasty shit when SSO magic is not available." This candid admission reflects the real-world compromises engineers often face.
Complex Automation
For more sophisticated automation workflows, community members discussed several orchestration approaches:
Workflow Engines
Commercial solutions: Itential, Ansible Tower/AWX
Open source options: Semaphore UI, Dagster, Temporal, Prefect
Lightweight alternatives: Celery for task queuing
Data Management and Artifacts
The question of handling automation outputs generated interesting responses:
Object storage: S3 buckets for storing script outputs and run artifacts
Database integration: Using tools like InfraHub or NetBox for storing results with network objects
Viewer applications: Streamlit interfaces for browsing historical runs and outputs
The Controller Challenge
A recurring theme was the complexity of working in "protected environments" where automation tools can't directly access network devices. This forces engineers to work through network controllers, adding layers of complexity to otherwise straightforward automation tasks.
This constraint significantly impacts tool selection and architecture decisions, often forcing teams toward solutions that can integrate with existing management platforms rather than direct device access.
Commercial vs. Open Source: The Eternal Debate
The discussion touched on the tension between commercial and open source solutions. Key points included:
Commercial Solutions
Pros: Professional support, comprehensive feature sets, enterprise authentication
Cons: Cost, vendor lock-in, potential for long-term technical debt
Notable mention: Itential received praise for comprehensive orchestration capabilities
Open Source Solutions
Pros: Flexibility, no vendor lock-in, community support
Cons: Self-support burden, potential maintenance challenges
Risk consideration: The specter of abandoned projects and "magic automation binaries" that nobody understands
Emerging Tools and Experimentation
Community members shared several tools worth monitoring:
Torero: A newer tool for launching Python scripts and playbooks, though still seeking production validation
Kriten: An alternative automation platform
NetiMate: A community member's side project for foundational network automation with plugin architecture
The consensus seemed to be cautious optimism about newer tools, with emphasis on production validation before adoption.
Practical Deployment Patterns
Small Scale (Under 50 Users)
Docker Compose on a dedicated server
Simple authentication mechanisms
Direct device access where security permits
Medium to Large Scale
Kubernetes orchestration
Enterprise authentication integration
Comprehensive logging and audit trails
Network segmentation and jump box architectures
Consultant/Multi-Client Model
Portable deployment packages
Flexible authentication models
Heavy emphasis on input validation and error handling
Key Takeaways for Network Engineers
Based on this community discussion, several patterns emerge for successfully deploying network automation:
Start Simple: Begin with working CLI tools before adding web interfaces
Validate Everything: Multiple layers of input validation prevent disasters
Plan for Authentication: Consider both application and device access early in the design
Choose Your Battles: Commercial solutions make sense for some organizations; open source for others
Consider Your Constraints: Protected environments and controller-based access significantly impact architecture decisions
Document and Test: The gap between working script and production tool is larger than most engineers initially realize
The Human Element
Perhaps the most valuable insight from this discussion is the emphasis on understanding your users and environment. The most elegant technical solution means nothing if it doesn't fit your organization's security requirements, skill levels, and operational constraints.
As the community discussion shows, there's no one-size-fits-all solution. Successful network automation deployment requires balancing technical capabilities with practical realities—and sometimes that means making compromises that prioritize operational success over technical perfection.
The Network Automation Forum community's willingness to share both successes and failures provides invaluable guidance for engineers facing similar challenges. Their collective experience demonstrates that while the technical hurdles are significant, they're entirely surmountable with the right approach and realistic expectations.
This blog post is based on a community discussion from the Network Automation Forum (NAF), reflecting the real-world experiences and opinions of practicing network automation engineers, including: Adam Angell, Christian Mas, David Sierra, Steinn Örvar, Chris Russell, Claudia de Luna, Pete Crocker, and Simon Di Giovanni. Individual approaches may vary based on specific organizational requirements and constraints.
