Network operations traditionally has been the missing piece in DevOps processes. It’s not difficult to see why. Network management has lagged behind server and workload automation. Updating network policies and configurations typically requires a great deal of analysis, testing and time, undermining the goal of DevOps agility. But once we shift how network devices are administered and how changes are validated, there are emerging ways to incorporate network updates and policies into DevNetOps processes through automation.
Shift the Focus to Policies, Not Configurations
DevOps has taken off, thanks in part to the ability of virtual networking and software defined networks (SDN) to automate the placement of workloads, establish connectivity and deliver Layer 4 to 7 services in a few minutes. But virtually all network policy updates, particularly those addressed in the underlay, were constrained by having to reconfigure individual network devices through traditional management platforms or command line interfaces (CLI). New application deployments may require new network paths, access to cloud resources, punching holes in firewalls, etc. There was no way to automate these policy-related tasks through existing network management platforms, and DevOps processes were limited to simple changes that could be made in the overlay network.
What’s wrong with updating individual network devices through CLI? Network administration is hampered by the inherent nature of IP networks individual devices never have a holistic end-to-end view of network policies and behavior. They are usually configured to know what to do with traffic locally, when to drop it and when to forward it to which nearest neighbor. This is not how policy requirements are formed (see Figure 1).
If a new DevOps deployment needs to ensure a rack in Data Center 1 can reach a rack in Data Center 2 through a specific secure gateway, then to a cloud-hosted database and return traffic appropriately, then we need a much broader, path-based view than any individual device or CLI can give us. If we are going to automate any of this analysis or verification, we are going to need a solution that maps our intended policy requirements to network implementations across many devices.
Intent-Based Networking Aligns With Policies and Intent
This is where intent-based networking (IBN) can help. IBN can help bridge our application policy requirements with the network design and configuration. It can allow us to verify if a particular policy requirement is supported in the network currently or help with a path-oriented search to quickly identify which devices need to be updated to deliver the particular policy. Changes, such as updating a firewall rule, ultimately may still be made to a single device through a CLI, but we have accelerated the analysis if the policy is currently supported, what changes need to be made and how such a change may adversely affect other existing policies and requirements.
For example, it may be an enormous benefit to application development teams prior to deploying a new workload, to be able to determine if connectivity from our Rack 1 servers to a remote database is available for new traffic requirements. Typically, this might involve a request to the network team, which would have to analyze the policy requirements or arrange for a test scenario. A trouble ticket request such as this would take more than just a few minutes, even if the network team could jump right on it.
Application Team Self-Service
Imagine instead the application team could self-service their request by querying an IBN system that could immediately verify the implementation of the policy. Perhaps the application team could use a simple internal messaging platform such as Slack to specify their policy requirement and get an immediate answer without further analysis by the network team. They wouldn’t even need to learn the GUI or capabilities of the underlying IBN platform with a Slack messaging front-end.
An IBN solution gives teams the power to avoid thinking in terms of individual device rules and opens the door to end-to-end automated policy analysis for the first time. Application teams could never be expected to understand firewall configurations or be able to self-service their queries about those capabilities, but they can think in terms of high-level application policy requirements and end-to-end path behavior, which IBN platforms can deliver (see Figure 2).
Automating Network Verification
To further accelerate key network policy changes required for DevOps processes, imagine updates are required to individual devices in the underlay network. Not only can those changes be identified nearly immediately now through IBN, but also the verification that the changes were made correctly and didn’t adversely affect any other applications or policy requirements can be completely automated. These IT tasks of analysis and verification were usually the most manual and time-intensive in the network operations workflow. But now that much of the workflow can be automated, DevOps can benefit greatly.
The verification process would consist of a long list of existing policy requirements that were already in place and implemented. After a proposed change to network configurations, all of those policies could be analyzed quickly to determine if the new update adversely affected any prior requirements, preventing rollbacks or potential security or compliance breaches.
The question naturally arises, What is really enabling this shift in network operations from a box-by-box focus to an end-to-end, path-oriented policy focus? IBN platforms have generally replicated much of the analytical intelligence of network engineers to determine overall behavior from analyzing individual device configurations and state information. Much of this intelligence is based on mathematical models of the running network in software and much less so now on analyzing live traffic under limited scenarios. This analysis of the mathematical model in IBN platforms now can provide definitive verification of policy requirements for the first time, and even identify configuration errors long before they can cause loss of service or an outage.
The key to accelerating network analysis and updates in support of DevOps processes is to shift focus up from individual box-by-box device management and CLI interfaces to focus on end-to-end network behaviors that align with application policy requirements. Application team self-service for many policy-related network requests and automation of network verification tasks are just a few of the benefits for DevOps teams that IBN can deliver today and into the future.
— Chiara Regale
