This is a co-authored blog: Lead Author is Quinn Snyder, Developer Advocate in Cisco Developer Relations, who specializes in the automation and programmability aspects of Cisco's Cloud Networking portfolio. Quinn worked in collaboration with Ravi Balakrishnan, Senior Marketing Manager at Cisco.
Software-defined networking (SDN) has brought a similar transformation to infrastructure that the cloud brought to applications -an ability to use a single point of control and management that can create consistent policy and configuration across any number of endpoint nodes. This has been a boon for infrastructure engineers and operators, as they are no longer reliant on manual tooling and processes to ensure the configuration is consistent across all the different end devices. In moving to centralized controllers with web UIs, however, on-premises infrastructure controllers also were originally subject to some of the same drawbacks as the control panels of the major cloud providers (or even some of the virtualization/hypervisor platforms) - lots of pointing and clicking to make operations happen.
"Click-ops" is not necessarily something that should be avoided at all costs. For many of the minor MACD (move, add, change, delete) work needed during the normal day-to-day operations of infrastructure, having a single UI to make a quick change that will then be distributed to the entire network really does simplify the process (remember, we are comparing this to having to push a single change by hand to CLI-driven devices). The challenge with "click-ops" is that it can be a burden on the operator to ensure that similar operations are done the same way, especially when many changes need to be performed within a single window. Luckily, the on-prem SDN controllers like Cisco APIC also adopted an API-driven mindset which enables automation at scale, especially when using an Infrastructure as Code-centric tool, like Red Hat Ansible or HashiCorp Terraform.
Now the only thing left to do is get started. But how? What platforms within the infrastructure are supported by IaC tooling? How can you practice building playbooks or plans without worrying about causing an outage in production? How can you be kept up to date with documentation and API changes across new versions of the platforms? That is where Cisco DevNet comes in, serving as a single source of truth for a complete developer reference and sandbox.
The DevNet Learning Labs are individual "quick-hit" labs that focus on a single platform and topic area (such as learning how to parse data with code, how to create an Ansible playbook, or how to build a Docker container). These labs are organized into multi-lab modules, which are then put into multi-module tracks. The net result is that a single Learning Track covers an entire platform (such as ACI) and the multitude of ways that automation can be used with that platform, including ways to get your feet wet with Ansible and Terraform for Cisco ACI, Cisco NDO (formerly MSO), and Cisco NDFC (formerly DCNM). Each lab comes with included sample code to review and use throughout your learning, allowing you to not just read how the modules and providers interact with the platform, but put it into practice using verified code. The ACI Learning Track and the DCNM/NDFC Learning Tracks are both constantly being updated with new modules as the platforms and capabilities change with the industry.
Figure 1 -Learning Modules within the ACI Programmability Learning TrackHaving labs and sample code is great, but it means nothing if you do not have an environment to learn on and experiment with (we do not always have the courage to test in production). DevNet hosts sandboxes (which are scheduled, created, and destroyed using automated processes, naturally) within our cloud to supply an immersive environment in which to dive deeper into the world of programmable infrastructure. You can practice Ansible with ACI using the ACI sandbox, instantiate EVPN fabrics using Terraform within the DCNM/NDFC sandbox, or even create application clusters using Intersight Kubernetes Service and Terraform Cloud for Business.
Figure 2 -CN Sandboxes within the DevNet SandboxMuch like the Learning Labs, the sandboxes are kept up to date with version updates and new platforms. Over the next few months, new sandboxes using the Nexus Dashboard platform will be added to support the next-generation datacenter controller platforms.
Sandboxes and labs are great, but they are a finite resource. Eventually, there will come a time when you must apply your skills to a production environment and may need documentation or code samples to cover what has been deployed in your environment. Every programmable platform hasversionedAPI documentation available. These reference guides supply information about the platform's APIs, its SDKs and IaC tool support, developer resources, and links to community support.
While references to IaC tooling are present within the documentation pages, DevNet also has two major microsites that cover Infrastructure as Code in depth across all CN platforms. The Nexus API and IaC Developer Centers supply quick access links to all things Infrastructure as Code, including the labs and sandboxes above, but also links to repositories hosted within DevNet's Code Exchange and Automation Exchange. These exchanges provide sample code and network automation samples that can be deployed into a sandbox or production environment with minor modifications to reflect your infrastructure. These can be used as is or added to larger automation projects to suit your needs.
Infrastructure as Code can be a wide and complex topic, especially when bridging between public cloud and on-premises resources. However, whether you are just getting started, have some familiarity with, or are an expert with IaC tooling, DevNet's website can provide you with resources to help you today and in your future automation endeavors.