Let's talk networking. And AI. And infrastructure. And everything. Register for Connect 2026
Megaport Connect
A first-of-its-kind virtual summit built to help network engineers and IT leaders upskill, share ideas, and connect around the future of cloud and hybrid networking
Learn how to automate networking infrastructure using Terraform, Ansible, and CI/CD pipelines.
This session covers network-as-code best practices including modular design, rollback strategies, and test coverage. Discover automation anti-patterns that increase operational risk, and how to build resilient, version-controlled network deployments.
Presented by: Chris Grundemann, Executive Advisor at Khadga Consulting, & Founder of Network Automation Forum.
Chris Grundemann, Executive Advisor at Khadga Consulting and Founder of the Network Automation Forum, presents a practical view of network automation at scale. The session is not framed as a tool-first discussion. Instead, it argues that successful network automation depends first on team structure, culture, design discipline, and trust, with tools chosen only after those foundations are understood.
The central theme is that network automation is software development applied to networking. That does not mean every network engineer must become a full-time software developer, but it does mean automation efforts need software-like practices: clear ownership, structured data, version control, testing, validation, documentation, APIs, and secure delivery workflows.
The technical discussion covers design-first automation, sources of truth, self-service interfaces, API gateways, Git-backed workflows, documentation as code, intent and observability patterns, and tool choices such as Terraform, Ansible, and Nornir. It also identifies common anti-patterns that prevent automation from scaling, including functional silos, black-box tools, monolithic systems, and attempts to solve every edge case before delivering value.
Network automation is often treated as a technology problem, but the session begins with an organizational point: the most advanced teams are not necessarily differentiated by programming languages, databases, or automation tools. Many organizations use similar categories of tools. What separates the teams that scale automation effectively is how they organize work and reduce handoffs.
Traditional network organizations are frequently structured by function. Network architecture designs the environment, network engineering implements the design, network operations runs it, and separate teams may own DNS, security, BGP, edge networking, or other domains. This can make sense from a skills perspective, but it creates dependencies between teams.
Those dependencies become silos. A network change may move from architecture to engineering to operations, with additional coordination across security, DNS, and other teams. Each handoff adds delay and ambiguity. This is one reason network changes have historically taken a long time.
The proposed alternative is to apply DevOps-style thinking to NetOps by treating the network as a large-scale software application. That requires cross-functional ownership of network services rather than sequential ownership by specialty teams.
The session adapts the four team types from Matthew Skelton and Manuel Pais’s Team Topologies model to networking. Although the model was written for software development, it maps naturally to network automation because automation work is software work.
Four team patterns are especially relevant:
The important point is not simply redrawing an org chart. The team model only works if it changes behavior. Automation scales when teams can own outcomes, reduce dependencies, share platforms, and collaborate across specialties without requiring every person to master every domain.
Organizational culture is presented as a foundation for scalable automation. The session references Ron Westrum’s typology of organizational cultures: pathological, bureaucratic, and generative.
In a pathological culture, power dominates and people may be punished for mistakes. In a bureaucratic culture, rules dominate, and following the process may matter more than the outcome. In a generative culture, performance and mission matter most. Generative organizations tend to have better information flow, stronger cross-functional collaboration, learning from failure, and continuous adaptation.
Those traits are directly relevant to automation. Automation changes how work is done, exposes hidden assumptions, and can surface defects quickly. Teams need the ability to share information, discuss failures without blame, and adapt based on evidence.
Psychological safety is also emphasized, but not as a vague instruction to be nice. Psychological safety means people can speak truthfully about problems, risks, and incorrect assumptions. Teams need to be able to say that something is broken, unsafe, or wrong so they can correct it. Without that honesty, automation systems may hide risk rather than reduce it.
A recurring problem in network automation adoption is starting in the middle. Teams often begin with operations tasks, sources of truth debates, Python training, or tool selection while skipping the design phase. The recommended pattern is to start with design and create a source of truth at the beginning, rather than later arguing about where the truth should come from.
Instead of beginning projects with a blank Visio diagram, design-first automation begins with structured data that can feed an automation pipeline. That data needs several qualities:
The workflow can be understood as plan, build, service. The planning phase combines input parameters, logic, and context to render a plan. The build phase makes that plan actionable by creating the required data, such as IP addresses, racks, devices, and related objects. This phase should use idempotency, rollback capability, and design protections. The service phase represents the resulting service as a managed object with lifecycle tracking, versioning, and ownership.
Three building blocks support this approach:
Many automation efforts begin as personal productivity scripts. An engineer writes something that solves a problem, then the organization eventually wants others to use it. The gap between a working script and a production-ready tool is larger than it may appear.
Trust is the deciding factor. If users are handed an opaque tool and told to press a button, they may hesitate because they cannot predict what will happen. Scalable automation needs interfaces, validation, safety, authentication, authorization, documentation, and testing.
The session recommends starting simply. A working CLI tool can be a valid first interface before a web application or self-service portal is added. As tools mature, validation becomes critical. Inputs should be validated at multiple layers, and graphical or command-line interfaces should constrain choices where possible. Drop-downs, allowed values, and guardrails reduce the chance of unsafe or invalid changes.
Authentication has two dimensions. Users must authenticate to the automation system itself, and the automation system must authenticate to devices, VPCs, APIs, or other targets it modifies. Both paths need to be designed rather than improvised.
The build-versus-buy decision depends on constraints. Commercial tools may make sense for some organizations and use cases, while open source tooling or custom development may fit others. Protected environments, controller-based access, cloud control planes, and on-premises access patterns can all affect the architecture. The right answer depends on the organization, not on a universal preference for a specific tool.
Traditional automation can bind teams tightly to a specific orchestrator. That creates two problems. First, some orchestrator costs scale with deployment size. Second, switching tools after hundreds of workflows have been built is painful.
An API gateway can act as an abstraction layer. The idea is to create a consistent API interface that can trigger automation regardless of what executes behind it. A source-of-truth webhook, a manual request, a playbook, a script, or a workflow can all consume the same interface. Teams use the API rather than learning every tool-specific interface, and the backend implementation can change without changing the consumer experience.
Several implementation patterns are possible:
This pattern is especially useful for event-driven automation, where events from multiple systems trigger automated actions. It is not always the right answer. Maintaining a custom microservices system can become its own form of lock-in, and some organizations may be better served by buying an orchestrator with support.
One established pattern is to use Git for logic and a network source of truth for data. The reasoning is straightforward: Git is strong at versioning static artifacts, while a purpose-built network data platform is better at modeling operational and relational network data.
Git is a good fit for:
A network source of truth is a better fit for:
These systems can work together. Jinja2 templates can consume source-of-truth API data to generate device configurations. Webhooks can propagate changes between Git commits, source-of-truth updates, and downstream network functions or devices.
Validation must occur in stages. Schema validation confirms that data fits the model. Syntax validation confirms that generated configuration is valid for the target system. A dry run, when a lab or equivalent environment exists, can show whether the change is likely to work. Deployment validation then checks before and after implementation to make sure the automation did not accidentally break something.
The pattern is evolving. InfraHub from OpsMill is described as a platform that combines a graph database with Git-like version control. That gives teams branching, diffing, and merging directly in the database, with schema flexibility and built-in validation and testing. This does not eliminate the Git-plus-source-of-truth pattern, but it changes the design space by combining data and version-control capabilities. NetBox and Nautobot are also noted as platforms with Git integrations that support the more traditional approach.
Network engineers often dislike documentation, but the session argues that documentation should be versioned alongside infrastructure changes. Documentation as code allows docs, diagrams, automation scripts, and templates to move through related pipelines instead of drifting apart.
The Diataxis framework is offered as a useful way to organize documentation by purpose:
Several tools and documentation methods are mentioned. MkDocs can generate a static site from Markdown. Kroki provides a unified API for diagramming tools, including Mermaid, making diagrams from code possible. C4 models can help communicate architecture to both technical and non-technical stakeholders. “Why” statements, similar to architectural decision records, document the reasoning behind technical choices so future teams can understand why decisions were made months or years later.
Larger organizations may go further with platforms such as Backstage and its TechDocs module. As with microservices, that can be valuable in complex environments but may add more management overhead than simpler documentation systems. The core recommendation is to document what can be documented and make that documentation part of the automation lifecycle.
The Network Automation Forum community has been developing a framework for thinking about scalable automation systems. The model separates intended state, actual state, orchestration, execution, collection, and presentation.
Intent defines the desired state of the network and includes the persistence layer that stores that desired state. This includes both configuration expectations and operational expectations.
Observability stores the actual network state. This is the measured or collected reality of the network, which can then be compared against intent.
Orchestration sits between intent and observability. It coordinates actions when intended state and actual state diverge. It also drives changes and coordinates collection.
At the lower layer, the executor performs tasks against the network, such as updating configurations. The collector retrieves actual state from the network and feeds that state into observability. At the top, the presentation layer exposes interfaces to users. Those interfaces might be dashboards, GUIs, CLI tools, or emerging natural language interfaces.
This framework helps teams decide what to build, what to buy, and how components should fit together. It also prevents automation from being reduced to a single script or tool. A scalable system needs a way to represent intent, observe reality, reconcile differences, execute change, and present safe interfaces to users.
Terraform can be useful for network automation, but it is not a universal answer. The main distinction is transactions versus resources.
Network operating systems often provide sophisticated transaction capabilities. A commit can include validation, confirmation, and atomic behavior across a set of related configuration changes. Terraform, by contrast, generally treats each resource as an independent API call with an implicit commit.
That difference matters when multiple network objects must change together. Creating an interface, a BGP neighbor, a VTAP, and a VRF through Terraform may result in four separate API operations, each committed individually. If one part fails or produces an unexpected result, rollback can become difficult.
Terraform may be a poor fit when managing traditional network devices directly, operating in mixed environments where some changes are manual and some are automated, handling complex inter-device transactions, or working with legacy infrastructure.
It can still be a good fit when the rest of the organization already uses Terraform, when managing security policies on firewalls, when building greenfield environments, or when strong CI/CD integration is important. Some teams use it successfully for network automation. The decision depends on whether Terraform’s model fits the operational behavior required by the network.
When Terraform is not the right executor or collector, the tool conversation often turns to Ansible and Nornir.
Ansible is positioned as an approachable powerhouse for teams that want to start quickly. It is YAML-based, does not require Python programming for basic use, has a large community, offers many tutorials and support options, includes built-in idempotency, and provides pre-built modules for common networking tasks such as configuring OSPF on Cisco routers.
Its drawbacks appear as complexity and scale increase. Troubleshooting can produce large, difficult-to-read error output. For large inventories or complex workflows, Ansible can be slow and may become frustrating.
Nornir is a Python-native alternative. For teams comfortable with Python, it feels natural because it avoids a separate domain-specific language. It can be much faster for large inventories, with the session describing performance up to 100 times faster. Debugging can also be better because Python tracebacks are clearer than Ansible’s error output. Nornir integrates with standard Python tools such as PyTest, Black, and Rich, and it can connect to web frameworks such as Flask and Django.
The trade-off is that Nornir requires Python fluency. Variables, functions, and nested data structures are prerequisites, not optional details. It also lacks enterprise support and has a smaller community with fewer learning resources.
The broader guidance is to match tools to organizational constraints and the work being done. Terraform, Ansible, Nornir, and other tools can all be valid choices when their strengths match the environment.
The session closes by identifying organizational and technical anti-patterns.
On the organizational side, functional silos are a major obstacle. If every automation-driven change still depends on handoffs between narrowly defined teams, the organization has not solved the flow problem. Stream-aligned service teams are presented as a better pattern because they own services end to end.
Another anti-pattern is looking for unicorns or trying to become one. Network automation combines networking, software development, systems thinking, security, operations, and organizational design. It is unrealistic to expect one individual contributor to master all of it. Organizations need cross-functional teams with dedicated roles and complementary specialization.
Perfectionism is also a blocker. Teams should not try to solve every edge case before starting. Incremental progress is more effective than waiting for a complete, idealized system.
On the technical side, automation should not become a black box. Citing guidance from Damien Garros, automation systems should be predictable, manageable, transparent, simple, reliable, and human-friendly. Users need to understand what a system is doing and trust the results.
Teams should also avoid monoliths. Automation should be modular and aggregated at runtime rather than built as one large, tightly coupled system. Security should shift left as well. Automation tooling needs to be secure by design rather than secured after the fact.
Network automation at scale is not achieved by choosing a single tool and applying it everywhere. It requires a system of practices that starts with design, organizes teams around services, and builds trust through validation, transparency, documentation, and secure interfaces.
The technical architecture should separate intent, actual state, orchestration, execution, collection, and presentation. Git, network sources of truth, APIs, documentation pipelines, and automation executors each have a place when they are used for the problems they are best suited to solve.
For practitioners, the practical message is to start with documented design intent, build incrementally, and make automation usable by teams rather than only by the person who wrote the first script. For decision-makers, the message is that scalable automation depends as much on culture and operating model as it does on Terraform, Ansible, Nornir, or any other specific platform.
With a Megaport Solutions Architect
We’ve helped hundreds of customers, just like you, to simplify their connectivity.
