Cisco Blogs
Share

What Does “Network as Code” Mean?


February 7, 2018 - 6 Comments

“Network as Code” comes from “Infrastructure as Code”

No matter where you turn in IT today, the impact of “DevOps” and “Cloud” can be seen and felt.  And this is with good reason.  The massive benefits that have been seen through agile processes, automation, and culture within software development are undeniable. It was only a matter of time before traditional infrastructure areas felt the pressure to learn and adapt.  The “Infrastructure as Code” (IaC) concept is one such area that has significant potential to disrupt and change how network engineering and configuration is accomplished.

“Network as Code” is the application of the more generic IaC concept to the specific domain of networking.

Network as Code

Network as Code is the application of Infrastructure as Code concepts across the entire network domain.

“Infrastructure as Code” is the name given to the techniques used to describe and provision the compute, storage, network, and other resources as part of the deployment of the modern applications in cloud platforms.  With IaC, developers embed the infrastructure requirements for the application right alongside the application code in the source control repositories.  These requirements are provided in data formats that can be easily processed by an infrastructure deployment tool.  While many tools for IaC deployment exist, a common multi-platform tool is Terraform by Hashicorp.  With Terraform, the infrastructure for an application can be quickly created, updated, destroyed, and recreated based on a “configuration” that is version controlled, along with the application itself.  Furthermore, Continuous Development (CICD) tools can perform the infrastructure management as part of the build pipeline.

The majority of cases where IaC is used today is within cloud environments, where the infrastructure requirements for an application were developed along with the applications that were built for the cloud, or migrated to the cloud.  It is much rarer to see true “Infrastructure as Code” leveraged for traditional data center, campus or WAN environments today, but I believe we are headed in that direction.

“Network as Code” (NaC) is the application of the “Infrastructure as Code” concepts to the full network domain, inclusive of traditional data centers, campus networks, WANs, and of course cloud environments.  The successful implementation of NaC is part of the wider NetDevOps adoption within an enterprise.  It will involve significant changes in the way we think about network design and operations, the culture around network change, and of course the tooling and technology used to build and manage configurations.  I propose three principles for Network as Code within NetDevOps.

Principles of Network as Code

  • Store Network Configurations in Source Control
  • Source Control is the Single Source of Truth
  • Deploy Configurations with Programmatic APIs

Let’s explore each of these principles in a bit more detail.

Principle 1: Store Network Configurations in Source Control

If we are going to have a “Network as Code” strategy, we need to treat the network configurations as code, and code is stored in source control.  In this case, I am referring to source control systems like “git“.  Also called version control, source control solutions enable efficient tracking of changes to files within “code repositories”, with tooling built to enable developers to easily work on their projects.  “Distributed Version Control” is the most common implementation of source control seen today and allows for the sharing of repositories among team members, by “pushing” changes up to a central remote location, from which other developers can “pull” to their local workstations.

By moving to source control systems, we leave behind more “traditional” methods of version control in network configuration space.  I am of course referring to common file naming strategies of “switch1-V1.txt”, “switch1-V2.txt”, “switch1-V3.txt”, and so on.  This method of version control is error prone, inaccurate, and lacks any method of accountability.  However with source control, all the versions are inherently stored within the repository history along with details such as who made the changes, when the change was made, and the reasons behind the change.  Furthermore, at any point you can quickly see the differences between different versions, and even “rollback” to any point in time with a single source control command.

Along with the underlying source control system, such as git, is the platform used to provide shared access to repositories across a team.  Products like GitHub, GitLab, BitBucket, Gogs, etc all provide an implementation of git in a web accessible portal where teams can share projects repos.  But these solutions offer far more than just a centralized remote location for repositories.  They also include collaboration features such as issue logging, release tracking, documentation wikis, project management boards, and much more.  This means that successful NetDevOps teams can leverage code reviews, issue logs, pull requests, and releases in the same way successful software development teams are.

Principle 2: Source Control is the Single Source of Truth

With our network configurations securely stored in source control, we now must treat the source control as the single source of truth for how the network is to be configured.  In many organizations today, the source of truth for the network configuration is the current running network configuration that is active in the production network.  That does provide the benefit that the running network is always “accurate” however it is a terrible way to manage in a modern “Infrastructure as Code” methodology.

Part of the reason behind “Infrastructure as Code” principles within cloud applications, is the ability to quickly and efficiently standup fresh instances of the infrastructure needed for an application within different environments.  Typical applications will have production, test, QA (quality assurance) environments as well as development environments for each active developer to work within.  By leveraging IaC methods each environment that is created will be constructed in the same way using the same configuration definitions, limiting variations between them to the bare minimum.  This greatly increases the successful application deployments and updates by removing environmental variation.  The reason this works is that the IaC configuration stored in source control is the source of truth for how the infrastructure is to be configured.

While most enterprises do not yet have the ability to have such a robust set of test, development, and QA environments for their overall network, there is significant work being done to bring that to reality.  Network simulation tools, virtual network functions, emulators, and cloud based solutions are all becoming available so, I envision a day soon when an enterprise can instantiate a “test network” that represents any part of their network.

And though we aren’t there yet, that is no excuse to not begin building the “Network as Code” and NetDevOps discipline today.  This means that the “correct” network configuration must be what is stored in source control and marked as the “production” release.  Any organic variations that are implemented by hand by a misguided engineer through SSH and CLI are deviations and incorrect.  With NaC we should be confident that at any point in time we should be able to implement the configuration stored in source control to our production network.  In fact, we should implement procedures that watch for deviations in running configurations, raise alerts and return to the known good configurations from source control.

Principle 3: Deploy Configurations with Programmatic APIs

The final principal of Network as Code relates to how the configurations from source control are actually applied to the network devices themselves.  As mentioned in the previous principle, manual configuration by network engineers is a deviation and mistake in a Network as Code world.  The human touch in the management of network configuration is in the design, development and testing of the Network as Code configurations.  The actual implementation of the “code” must be done through programmatic APIs.

There are many reasons why this principle is so important, but they all really break down to two points: consistency and scale.  The human mind is an amazingly intelligent and creative force of nature, however it is also easily bored, terrible with minute details, and not built for repetitive tasks.  The execution and implementation of network configuration across an entire network is one that will stress all of the human weaknesses.  Thankfully, computers do not get bored, are excellent at details, and are specifically designed for repetitive tasks – and this third principle takes advantage of that fact.

So, if we agree that computers are better suited for deploying configurations across the network, it only makes sense that we use interfaces that are best suited to computers and not ones suited to humans.  This of course means that with Network as Code we will leave behind the CLI as the primary method for deploying network configurations, and move to APIs such as the new standards of NETCONF and RESTCONF or native platform APIs.

However, we must also consider a bit of reality at this juncture.  Modern programmatic APIs are still relatively new to network infrastructure, and many of us have networks built with platforms that may lack an interface other than CLI (or SNMP which has its own challenges for configuration).  This fact does not prevent us from beginning to move towards “Network as Code” and NetDevOps. It just means that for a point in time we will need to leverage the CLI as the programmatic API, in some cases.  Once the legacy platforms are upgraded (either in software or hardware) and gain a better API choice, we can update our deployment strategies.

Conclusion

In this blog post, I wanted to begin exploring how “Infrastructure as Code” concepts will relate to the wider network as we begin to fully adopt NetDevOps and move to “Network as Code”.  If you’re asking yourself what exactly “NetDevOps” is, please checkout Part 1 and Part 2 of my blogs on that topic.  There are many more topics to consider as we move in this direction so be on the lookout for more blogs!  Next up will be a discussion on configuration management concepts and tools and what they offer to the network.

 

See Network as Code in Action

If you like what you’ve read, and want to see a bit more. Checkout this NetDevOps video where I provide a bit of a demonstration of “Network as Code in Action”.



In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.

6 Comments

  1. Great article, Hank. Looking forward to the future one on source code. Especially curious on how to maintain synchronization between device config and git config (especially with api and traditional CLI changes).

  2. Good starter. Will you be tackling more advanced topics like secrets management, CI/CD pipelines and moving beyond config replacement and into orchestration? Maybe something involving event driven automation?

    • Dhana, my plan is to continue discussing and building content and ideas around all the topics in the NetDevOps space including the ones you listed. No specifics on the order or timeline for when I'll cover them. Mostly will be up to available time and other factors that push me in one direction or another.

  3. Would You also mention tools for IOS Syntax checking? Most Systems in production are so called „legacy“. No API only IOS NXOS AireOS syntax. So the best Syntax checks are on the systems themself. Lightweight emulators, or still some rare vIOS vNXOS vAireOS or Hardware, many Hardware.

    • Absolutely correct. Syntax checking for CLI is definitely a challenge for legacy interfaces that lack a data model schema that can be validated against. In those cases, the best solution is thorough testing of templates in non-production environments, and strict adherence to those templates.

  4. I'm all about the human touch, but I completely agree that humans are error prone. Let's automate from the core, and reserve the finer human details for final packaging, focused on the user experience.