Network Automation Architecture – Introduction

Welcome to this blog series about Network Automation Architecture! Because you are here, most likely you are aware of the benefits of network automation. This post will explain a structured way to adopt this automation mindset that will help you get started.

At NTC, we have been solely focused on network automation since 2014, evangelizing the benefits (and challenges), developing open source software, and implementing real solutions to automate network operations. This experience has taught us how to organize the different elements that compose a network automation solution. Even though every solution is different, we have been able to identify some patterns from the different projects.

We realized that grouping the component functionalities in blocks with clear purposes and boundaries was helpful for us, and for our customers. Internally, it helped us to reuse components between projects, only modifying the custom logic. But more importantly, it helped our customers to better understand the proposed solutions, for later maintainability and extensibility.

We believe in the community, so we want to share what works well for us. We have already shared these concepts in some public conferences, such as FOSDEM, FOSSASIA, ITNOG and GRNOG.

To align expectations, you should expect a simple architecture without dozens of layers or complex dependencies. We leave this for academic papers. Our goal is to make it simple, with easy-to-understand functional blocks.

Network Automation Architecture

A network automation solution is rooted in transforming (and improving) a network operation workflow, making some (or all) steps automated. Every step should have a purpose (if not, it’s time to drop it). This means that we will have a list of tasks/functionalities to be automated.

The goal of this architecture is to help you answer the question: Where should I start?

We propose an architecture with six blocks, each of which has a clear goal. This helps to follow a systematic approach. First, mapping the workflow steps into these blocks, and finally, finding the right tooling to implement them. Any block may contain multiple tools, or a tool can be applied to multiple blocks. Also it’s okay to skip blocks if there are no related tasks needed in a network automation workflow. This is only a reference framework.

We will cover these blocks in more detail throughout this blog series. Here, we simply introduce them, with a one-line description:

• Network Infrastructure: Includes all the components of your network: physical devices, virtual functions, and cloud services.
• User Interactions: Offers proper entry point for the network automation solutions.
• Source of Truth: Defines the intended state of the network.
• Automation Engine: Implements tasks related to changing the state of the network.
• Telemetry and Observability: Obtains and monitors operational state data.
• Orchestration: Connects all the automation steps to implement the desired workflows.

All the blocks are interconnected via Application Programming Interfaces (APIs), such as REST API, GraphQL, or webhooks. These interconnections, which we usually refer to as External Integrations, are leveraged by other architecture blocks or external tooling.

Implicit to all the architecture blocks, there is the usage of Software Development Life Cycle (SDLC) best practices: from application development, when creating new solutions, to operational excellence to deploy and run them, adopting Infrastructure as Code. This includes using peer review for any change, applying testing via Continuous Integration, and deploying in pre-production environments before actually bringing a new/updated solution to production.

What’s Next?

This is the first blog post in our series about network automation architecture. In the next blogs, we will deep dive into the architecture blocks, analyzing the required functionalities, the necessary features, common use cases, and challenges.