Now that we’ve covered NFV, our journey through the evolution of network operations brings us to Infrastructure as Code (IaC). IaC is a concept from datacenter virtualization and especially cloud and DevOps that makes things repeatable, automatable, and verifiable by leveraging abstraction and flipping the source of truth.
Just like virtualization, the “server folks” (or more accurately the developers) got here first. In many ways, IaC is the natural outgrowth of server virtualization. Today, turning up a server usually means creating a VM, a container, or multiple of either. And of course that is done not by physically racking and connecting a device but by typing some commands into a VMware, AWS, GCP, Azure, or other management interface. These commands are now creating your infrastructure.
Infrastructure of Abstractions
This is an abstraction - of course there must still be hardware underneath. The dirty little secret of software is that it all runs on hardware. But in the cloud, as well as any properly provisioned and virtualized data center environment, we can now assume that the basic HW requirements are present. That frees us to use commands to apply the available resources as needed for our application. Of course, instead of typing the needed commands into a user interface, we can leverage APIs, declarative definition files, version control systems (such as Git), and automation tools to do it all with code.
From a developer perspective, this makes complete sense. It’s exactly how software has been written for decades. And that’s kind of the point. One of the fundamental principles of DevOps is to treat infrastructure the same way developers treat applications. When the infrastructure is defined by software (code), you can then treat that software as you would any other development project. Ideally, it actually becomes part of the development project. The files defining the needed infrastructure ride along with the files defining the application. And just as the same source code always produces the same binary, the same infrastructure definitions always create the same environment.
Advantages of Infrastructure as Code
This highlights one of the key advantages of IaC - repeatability. By defining the needed infrastructure (such as virtual machines, containers, load balancers, firewalls, network topologies, etc.) as code, we can ensure that every developer is working in the same environment that their application or feature will eventually be deployed into. We are not managing the infrastructure device by device, or even environment by environment; we are defining it once, and applying that definition everywhere it is needed. This level of repeatability is referred to as being idempotent.
That, combined with its other two primary advantages (automatability and verifiability) are what make IaC a needed component in continuous integration, continuous delivery, and ultimately continuous deployment (collectively CI/CD). Because it provides a standardized, idempotent definition of the needed environment, deployment of that environment can be performed automatically with tools like Chef, Puppet, SaltStack, Ansible, or Nornir. And because it’s defined with standardized declarative code, the environment can always be validated against its definition. In fact, you can perform automated verification (/validation) both pre and post deployment - just as developers do with their application code.
Network as Code
How do we apply this concept of IaC to networking? Well, as you may have noticed above, in many cases we already have. For cloud-native applications being built, tested, and deployed completely within a public (or private) cloud, the basic networking requirements are almost certainly part of the IaC being developed and maintained along with the application. But most networks are far from this potential ideal state. So, how do we get there?
How To NaC
There are a few basic requirements needed to implement our network as code (NaC). First, we need a stable, physical network with plenty of capacity and redundancy. Next we need to leverage network virtualization and network function virtualization to abstract the overlay networks we want from the underlay networks we need. Then we move our source of truth from the on-device configuration text to a centralized repository leveraging version control. And finally, we need a tool to push accepted configuration changes from that repository out to all of the devices and functions that make up the network.
A key to making this work is a personal, mental paradigm shift. We can no longer think about changing the configuration on a specific device. To leverage NaC we need to think of the network as a distributed system that is controlled by the declarative definition files managed through our version control system. If I want to change the behavior of the network, I never log into one or more devices directly. Instead, I just change the code that defines the network and then use an automation tool to push my (approved) changes out to all of the devices and functions that need to be updated, all at once.
Beyond (Network) Infrastructure as Code
The next article in our “NetDevOps Primer” series will leap into the paradigm shifting concept of Intent Based Networking (IBN) - so, tune in next month (dropping mid-June 2024)!
For those with less patience; everything in this series is available RIGHT NOW in the FullCtl whitepaper: The NetDevOps Primer.