An Automation Journey: From ACI to IAC With Terraform

In the past few years we, as an industry, have observed a pattern of data center architectures evolve from distributed networking systems to centralized software-defined platforms.

The rise of such platforms, like Cisco ACI, has not only allowed us to holistically define what infrastructure should look like but also what desired outcomes we should be able to achieve, thereby opening the door to an era of "Intent-Based Networking". 

Such type of functionality is highly augmented when vendors decide to expose the majority of their platform's capabilities via RESTful APIs.

Having a solid API exposure allows infrastructure (network, storage, compute, virtualization) to be programmatically consumed and benefit from many enabling aspects, such as speed, agility and accuracy.

Specifically to Cisco ACI, its RESTful API has allowed for many forms of consumption ranging from concrete (imperative configuration and explicitly defined) to abstract (declarative configuration and intent based).

Here are a few examples of approaches:

This advent has opened the way for platform administrators to be able to codify their infrastructure and declare what it should look like as opposed to how we specifically configure it. Enter, Infrastructure as Code (IaC).

In this programmatic era, it is great to have the capability to just declare what your preferred SDN platform should look like, in a human-readable configuration file.

One specific tool excels at this notion of IaC — Terraform by HashiCorp. According to HashiCorp, Terraform is a tool for building, changing, and versioning infrastructure safely and efficiently. And guess what? Terraform is now featuring Cisco ACI support.

Terraform has Cisco ACI support via Terraform Provider, which is responsible for understanding API interactions and exposing resources.

In the context of Cisco ACI automation, the real value lies in declaring what the infrastructure should look like. Then, Terraform will reach out to Cisco ACI and programmatically configure every relevant construct within it without explicitly declaring every knob one would need to configure, repetitively, via a GUI or command-line interface.

Here is a brief example of what an ACI Tenant creation within Terraform would look like, from a declarative Infrastructure as Code perspective:

In the example above, I have described what my ACI infrastructure should look like and Terraform will pick this "declaration" definition and will create its associated constructs (in this case, a Tenant) inside ACI.

Infrastructure "codification" does not have to be difficult, and with tools like Terraform abstracting through simplicity instead of complexity, infrastructure administrators will be in a privileged position to embark on an evolutionary journey from a "point and click" to "code and deploy" in a simple, repeatable and scalable way.

Want to try ACI?

Our labs are on-demand, include easy to follow step-by-step instructions and there is no charge to use them. Learn more about a few of our ACI offerings: Cisco ACI Basics and Deploying an ACI Multisite Fabric Module 1 of 4.