Let's Talk About Moving from CLI to Network Automation
This isn't another "automate or die" lecture. We'll cover working smarter in a world that's moving faster than ever.
By now, you've probably realized that network automation is crucial for businesses to stay competitive and boost efficiency. As companies keep up with the digital age, the need for automation in networking has become clear.
Although the main goals, like maintaining consistent uptime, ensuring strong security, and boosting performance, stay the same, the expectations in these areas have grown considerably. Today, organizations realize that delivering top-notch uptime, security, and performance is no longer just a plus; it's a must to succeed in a rapidly changing tech landscape. Implementing advanced network automation solutions is no longer a choice; it's a necessity for success in today’s market.
Today, there's a pressing need to meet demands and complete tasks more efficiently. If you’ve developed your skills as a network engineer, mainly using CLI, it's time to fully adopt automation.
Mastering network automation won't happen overnight. It'll take a lot of time, effort, money, and hard work. I recommend starting by learning the basics and experimenting with code and scripts for various purposes, but keep in mind these aren't ready for production. You're just getting familiar with working with code, not the CLI. Think of this as the first chapter in your network automation journey; it'll be invaluable as you move forward.
That said, be cautious, as explained below.
Watch Out for the Cowboy Coder Trap
Suppose you're in an environment where software-defined networking is considered advanced, and you have the opportunity to learn on the job established software development (SysDev) processes and frameworks. In that case, you can learn, adapt, and deliver results relatively quickly. However, this reality is mainly found in major tech companies like Amazon, Google, and Meta, while many others are still lagging behind.
Now, if you're leading the way in network automation within your organization but lack experience in how software teams work, tread lightly! You might unintentionally create problems and make situations worse, which could lead to setbacks.
Network automation must not be limited to specific tools or pieces of code; it’s a much broader strategy for managing and enhancing network systems. It’s about building a solid software culture for network engineering and operations.
If you’re driving this change in your organization, focus not only on writing code but also on understanding the core needs and how to manage your network effectively. Aim to deliver real value, not just snippets of code.
When Automation Backfires: The Hidden Cost of Skipping Software Design Principles
The rise of network automation has empowered a new wave of engineers to deliver incredible value, accelerating operations, reducing toil, and enhancing observability. But there’s a darker undercurrent we need to confront head-on:
When automation is implemented without a foundational understanding of software design principles, the consequences can be severe.
This is not a critique of network engineers, quite the opposite. The discipline of networking is deep, rigorous, and complex in its own right. But writing software, good software, requires a different mental model. Without proper design hygiene, automation becomes fragile, opaque, and eventually dangerous.
Let’s break down what happens when this gap is ignored.
1. Fragile Systems That Don't Scale
Scripts written ad hoc often grow organically and without structure. These start as helpful tools: a loop here, a conditional there. Over time, they balloon into mission-critical automation that no one understands or can confidently modify.
Common pitfalls include:
Hardcoded variables (e.g., IPs, credentials, device types)
Lack of modularity, making reuse impossible
Zero error handling, so one edge case breaks everything
Single-threaded assumptions, leading to concurrency issues
No abstraction layer, tightly coupling the logic to specific platforms
This creates non-deterministic behavior in automations that work under some conditions, fail under others, and cannot be trusted at scale.
2. Lack of Idempotency and State Awareness
A major principle in infrastructure automation is idempotency, the idea that running an automation multiple times should produce the same result.
Network engineers without a software background often write automations that assume an initial clean slate. When run on systems with drift or partial states, they:
Duplicate config entries
Wipe out valid configurations
Create race conditions
Trigger unnecessary rollbacks or alerts
Without proper state validation and reconciliation logic, these automations become destructive instead of declarative.
3. Operational Risk and Outage Amplification
Poorly designed automation has the potential to amplify outages instead of preventing them.
Some real-world failure patterns:
A script with a malformed loop disables interfaces across the wrong segment
Automation meant to update BGP neighbors accidentally wipes entire routing policies
A typo in a variable name gets pushed to hundreds of devices due to a lack of testing or peer review
When you combine:
No version control
No rollback strategy
No dry-run or staging mode
…you’re setting yourself up for operational chaos.
4. Lack of Observability and Debuggability
Well-designed software systems are observable. They emit logs, metrics, and structured events that help you diagnose issues. By contrast, many network automation tools written without design discipline lack:
Timestamped logs
Structured error messages
Contextual debug information
Clear execution traces
This makes incident response and troubleshooting painfully slow and prone to errors. In critical moments, your automation pipeline should be an ally, not an enigma.
5. Technical Debt and Team Burnout
Without maintainable structure, automation becomes a liability:
New engineers are afraid to touch the codebase
The original author becomes the only person who understands it
Onboarding slows to a crawl
Every feature request feels like open-heart surgery
This leads to automation paralysis, where engineers stop improving tools because the cost of change is too high. What began as a productivity enabler now becomes a blocker.
Worse still, this burden often falls on one or two individuals, leading to burnout and systemic fragility.
6. No Testability, No Trust
In software development, code is tested before it hits production.
But many network automations skip this entirely:
No unit tests
No mocks or simulators
No canary deployment strategy
This lack of test hygiene means changes are pushed live and only validated by whether something broke afterward. That’s not automation. That’s gambling.
So What’s the Alternative?
Bridging the gap doesn’t require you to become a full-stack developer overnight. But it does require adopting core software principles:
Modular code design (functions, classes, reusable components)
Idempotency and state validation
Configuration from data, not logic
Version control, change review, and CI pipelines
Observability through logging, metrics, and error handling
Unit and integration testing with stubs/mocks
Reconciliation design principles and systems
Your scripts should evolve into tooling.
Your tooling should evolve into platforms.
And your platforms should be built with intent, safety, and resilience in mind.
📘 Practical Checklist: Applying Software Design Principles to Network Automation
1. Planning and Requirements Gathering
Before writing a single line of code:
🔲 Define the automation’s goal. What outcome are you trying to achieve?
🔲 Understand the network context. Devices, platforms, protocols, existing tools.
🔲 List failure modes. What can go wrong? What must never break?
🔲 Determine inputs and outputs. YAML/JSON config? CLI commands? API calls?
👉 Pro tip: Treat automation like a service, not just a script. Know the user, know the blast radius.
2. Version Control and Collaboration
🔲 Use Git from day one. Every automation effort should live in a versioned repository.
🔲 Commit early and often. Small, descriptive commits make code easier to track and debug.
🔲 Use branches for changes. No direct commits to
mainormasterorproduction🔲 Peer review every change. Use pull requests to improve code quality and share knowledge.
👉 Even solo engineers benefit from version control; it’s your audit trail, rollback plan, and documentation.
3. Code Structure and Readability
🔲 Modularize your code. Functions or classes for distinct tasks (e.g.,
get_devices(),build_config()).🔲 Avoid hardcoded values. Use configuration files (YAML, JSON) or environment variables.
🔲 Follow consistent naming conventions. Variables, functions, files should be predictable.
🔲 Write docstrings and inline comments. Explain why, not just what.
👉 Good code is easy to read, easy to reason about, and easy to change.
4. Idempotency and State Management
🔲 Ensure actions are idempotent. Running automation twice should not cause side effects.
🔲 Validate pre-state and post-state. Read the current state before acting; verify after.
🔲 Use dry-run or "check mode." Preview changes without applying them.
🔲 Support rollback or undo. Always ask: “Can this be safely reverted?”
👉 Intent-based design means managing desired state, not just pushing config.
5. Error Handling and Logging
🔲 Catch exceptions and errors. Use
try/exceptblocks with meaningful messages.🔲 Log every significant action. Include timestamps, hostnames, operation details.
🔲 Use structured logging (e.g., JSON logs) for easier parsing and analysis.
🔲 Fail safely. If one device fails, continue or rollback cleanly.
👉 Logs are your black box recorder. Design for visibility, not guesswork.
6. Testing and Validation
🔲 Write unit tests for logic. Test functions in isolation with known inputs/outputs.
🔲 Use mock devices or simulators. Avoid testing on production equipment.
🔲 Build validation checks. Did the automation achieve the intended result?
🔲 Automate test execution. Use tools like
pytest,tox, or CI pipelines (GitHub Actions, GitLab CI).
👉 If it’s not tested, it’s not trusted. Test coverage prevents fire drills later.
7. Deployment and Execution Strategy
🔲 Start in a lab or staging environment. Validate behavior before production.
🔲 Use progressive rollout. Test automation on a subset of devices first (canary).
🔲 Track version deployments. Know what version of automation ran where and when.
🔲 Limit blast radius. Never make changes to the whole fleet in one go.
👉 Automate cautiously. Measure twice, push once.
8. Documentation and User Guidance
🔲 Write a README. Explain what the automation does, how to use it, and what to expect.
🔲 Document dependencies. Python versions, required libraries, credentials, etc.
🔲 Create usage examples. CLI inputs, config file templates, expected output.
🔲 Keep changelogs. Track major updates and behavior changes.
👉 Documentation is part of the product. Make it easy for others (and future you) to understand.
9. Observability and Monitoring
🔲 Expose metrics. Track execution time, success/failure rates, impacted devices.
🔲 Send logs to centralized systems. Use syslog, ELK, or cloud-native tools for visibility.
🔲 Emit alerts on failures. Notify engineers when automations fail or produce unexpected results.
👉 You can’t fix what you can’t see. Instrument your automation like production software.
10. Continuous Improvement
🔲 Schedule regular reviews. What worked? What failed? What needs refactoring?
🔲 Refactor for reuse. Turn isolated scripts into shared modules and services.
🔲 Promote a culture of software quality. Coach peers, introduce standards, and mentor others.
🔲 Stay current. Follow open-source communities, libraries, and vendor SDK changes.
👉 Good automation evolves from tool to framework to platform.
💡 Quick Start Recommendations
For engineers just getting started:
Goal | Tool |
|---|---|
Version control | Git + GitHub or GitLab |
Automation language | Python |
Device access |
|
Configuration mgmt | Ansible, Jinja2 templating, Pydantic |
State validation | PyATS/Genie, Scrapli |
Testing | Pytest, |
Observability | Logging + Prometheus (optional), SuzieQ |
Documentation | Markdown, MkDocs, Sphinx |
Final Advice: Build It Like You’ll Hand It Off Tomorrow
You may be the first person writing network automation in your org, but you won’t be the last.
Build your tooling so that:
It’s understandable without context
It’s safe by default
It’s easy to test
It’s a foundation for others
That’s the difference between writing scripts and engineering systems.
Concluding…
Network automation can greatly enhance the efficiency of managing computer networks, but it needs to be based on strong principles to be effective. If it lacks these guiding rules, it becomes unstable and unreliable.
However, with solid foundations in place, network automation will serve as a powerful tool for driving progress and innovation.
I hope you enjoyed this content. Let me know in the comments!
Leonardo Furtado