Infrastructure as Code for Network Automation
We believe we are at an inflection point as the slow, steady progress towards standardization and APIs has been replaced by a frenetic response to the business and automation demands that are being placed on the network. What has historically been allowed to work independently at their own pace for risk mitigation purposes is now being thrust into the forefront of digital transformation strategies. While no one can argue the critical nature of networking to their digital and cloud strategies, we need to rethink a more aggressive response.
The network industry is grappling with a number of network management challenges that have become increasingly problematic over the past decade and which show no sign of slowing down. Challenges include:
- Network Complexity – Business drivers are generating new ways to connect users and applications which is making networks much more complex in a world of cloud-first, secure enterprise networking.
- Network Velocity – Applications are driving network changes at an alarming rate which requires us to support a world of machine APIs over a human-first mindset.
- Network Cloudification – There is a push for Enterprise Data Centers to look more like Public Cloud infrastructure along with the management tooling to be API-first and support machine-first behavior.
- Network Virtualization – Much of the network infrastructure is being virtualized with the goal of having flexibility in network architectures without the need of deploying new physical infrastructure.
- Network Silos – Network Silos must be eliminated by integrating networking activity with the rest of IT, Security, and Cloud Automation strategies.
In response to these challenges, the industry has been working on a number of initiatives to support the move to a more integrated, programmable, network-first automation ecosystem including:
- DevOps – The working model for Cloud platforms is being adopted by Network teams to ease the transition into agile practices.
- Controllers – SDN principles are being applied to all modern networking services allowing for programmable interfaces and a source of truth for the scope of responsibility for the Controller.
- OpenAPI generated interfaces – Services to auto-generate integrations from Swagger/OpenAPI interfaces are allowing organizations to further accelerate network programmability. Conforming to the OpenAPI Spec is simple enough so that most enterprise software and network equipment vendors are publishing their REST interfaces to ease consumption efforts for customers.
It’s Time to Treat the Network as Software
Although progress has been made in the networking domain, it is important to look to other peer groups for solutions that allow massive numbers of people to jointly collaborate and make changes in a controlled and repeatable process. For example, software developers once stored their configs in code repositories and ran into similar problems once the size of their teams and velocity of change reached a breaking point. Their response was to adopt modern software principles to scale the team’s ability to support by initially incorporating some version of source control like Git and then using a CI/CD pipeline to build, test, and deploy.
While attractive, issues arise when trying to implement the CI/CD approach in networking. Specifically, there generally isn’t a consistent source of truth. There may be several templates that are each responsible for chunks of the configuration, but the actual final built version of each configuration is only available on each specific device
One way to solve these problems is by building API services and tools that better enable network engineers to achieve similar CI/CD goals such as scalability, agility and velocity all without discarding legacy network investments and conforming to a brand-new paradigm. By aligning with modern agile software engineering practices while staying flexible enough for customers no matter the current level of automation, we can conceivably embrace the innovation and benefits of a Network Infrastructure as Code strategy. The question is how?
The NetOps pipeline – Build, Validate, Test, Deploy
In the network universe, it is difficult to “compile” configurations as one typically does in the build phase of CI/CD pipeline. To accommodate, the NetOps pipeline breaks the traditional build phase into two components. The first is the build phase where one builds complete configurations from external data and/or blocks of pre-built configurations. The second is the “validate” phase which checks to see if a configuration is compatible with the device without having to deploy it. The combination of these two phases helps approximate the type of work a compiler might do during the build phase.
The third phase of the NetOps pipeline is testing services to make sure changes do what they were intended to do. For example, if changing an ACL policy on a device, one can run a series of tests against that policy to simulate what would happen for multiple scenarios.
The final phase of the NetOps pipeline is deployment. This is where our industries investment in programmable infrastructure will support automated pipelines. We can largely leverage CI/CD for aggregate Testing & Validation, but we can leverage the ecosystem of network integrations to safely deploy intended changes to the network.
As network organizations continue to explore and adopt automation as a way to tackling today’s network management challenges, it is important that innovation continues to support a more integrated, programmable, network-first automation ecosystem. The modern software development CI/CD pipeline provides an important roadmap to achieving those goals in the network domain. There’s no need to recreate the wheel.