Infrastructure as Code provides network operators with the ability to describe the intended configuration of the network in a structured data model. This data model is then used to generate the configuration for the network devices.
Originating from the DevOps movement, Infrastructure as Code has been widely adopted in the cloud to automate the deployment of virtual infrastructure. NetAsCode brings this concept to the network, allowing network operators to automate the deployment of network configurations in a similar way.
Utilizing Infrastructure as Code opens the door to a number of benefits for network operators. The first and foremost is to centralize how automation is run and managed. Gone are the days of operators running scripts from their laptops or servers. Instead, automation is run from a central location, ensuring that the automation is consistent and reliable. This also allows for the automation to be version controlled, allows for the automation to be reviewed and testing before and after network changes are made.
NetasCode aims to reduce time to value by lowering the barrier of entry to network orchestration through simplification, abstraction, and c durated examples.
It allows users to instantiate network fabrics in minutes using an easy to use, opinionated data model. It takes away the complexity of having to deal with references, dependencies or loops.
Focus on describing the intended configuration while using a set of maintained and tested Terraform Modules without the need to understand automation languages and procedures.
Integrated testing without the need of defined test cases. NetasCode automatically verifies that the intended configuration is applied correctly against the declared data model that represents the network configuration.
These benefits are built on a foundation of an automation pipeline that can be integrated into your business operations.
The NetAsCode pipeline is a series of steps that are executed to configure your network infrastructure. The pipeline is executed by changes pushed via DevOps practices to the core data model of NetAsCode.
- Operators define intent in the data model. This is known as the declarative method of configuration. This source of truth provides a central location for the configuration of the network.
- The data model is then validated against the schema to ensure that the configuration is correct. This is also known as linting.
- Once all validation is completed, the pipeline passes the execution to the automation engine. The automation engine then generates the API calls required to configure the network devices.
- To validate that the configuration is correct, the pipeline will then run tests against the network devices to ensure that the configuration is correct.
- Finally operators are notified of the results of the pipeline execution.
Once you have established this automation architecture, changes to the network are executed from a central location. Gone are engineers using playbooks stored on personal computers and servers that only a select few understand.
At the core of NetAsCode is the data model. This data model provides a simplified way to describe the network configuration. In the following example you can see the comparison betweeen HCL ( Hashicorp Configuration Language ) in contrast to the data model of NetasCode. NetasCode focuses just on defining the network intent from the network operators. Under the covers NetasCode takes the data model and translates it into the process and parameters required to configure the network devices.
Each technology space ( ACI, SDWAN , NDFC ) has it's own unique data model designed by network engineers to simplify how to capture the intended network configuration. This allows for a representation of configuration elements that is easier to understand by network operators.
ACI
NDFC
SDWAN
ISE
MERAKI
CATALYST CENTER
When Cisco network engineers define the data model, they define the specific values corresponding to each element. This specificity ensures that when the operation is executed in production, it is accurate and consistent.
Utilizing Yamale, NetAsCode performs linting on the data model against the defined schema to ensure that the configuration matches pre-defined formats and values. This allows for the early detection of errors in the configuration before deployment minimizing the risk of errors during change deployments. The schema specifies the expected structure, input value types (String, Enum, IP, etc.) and additional constraints (eg. value ranges, regexes, etc.)
This validation is then incorporated in your processes that can be used to perform Format, Syntax Semantic and compliance checks.
As the complexity of the configuration defined by the data model increases, automated validation plays a critical role in ensuring that the configuration is correct.
In addition rules can be coded into the schema that augment the defintion of the schema in the data model. These can include examples like:
- Ensure a specific naming convention is applied to specific objects.
- Mandate specific configuration parameters that meet best practices defined by your network operations team policies.
Just to name a few.
NetAsCode provides a testing framework that automatically verifies that the intended configuration is applied correctly against the declared data model. In addition to validate that the configuration on the device matches the declared configuration, NetAsCode can also validate some operational aspects of the network based on defined expected network states, ensuring that upon configuration changes the network is operating in the expected state.