DevOps.com

  • Latest
    • Articles
    • Features
    • Most Read
    • News
    • News Releases
  • Topics
    • AI
    • Continuous Delivery
    • Continuous Testing
    • Cloud
    • Culture
    • DevSecOps
    • Enterprise DevOps
    • Leadership Suite
    • DevOps Practice
    • ROELBOB
    • DevOps Toolbox
    • IT as Code
  • Videos/Podcasts
    • DevOps Chats
    • DevOps Unbound
  • Webinars
    • Upcoming
    • On-Demand Webinars
  • Library
  • Events
    • Upcoming Events
    • On-Demand Events
  • Sponsored Communities
    • AWS Community Hub
    • CloudBees
    • IT as Code
    • Rocket on DevOps.com
    • Traceable on DevOps.com
    • Quali on DevOps.com
  • Related Sites
    • Techstrong Group
    • Container Journal
    • Security Boulevard
    • Techstrong Research
    • DevOps Chat
    • DevOps Dozen
    • DevOps TV
    • Digital Anarchist
  • Media Kit
  • About
  • AI
  • Cloud
  • Continuous Delivery
  • Continuous Testing
  • DevSecOps
  • Leadership Suite
  • Practices
  • ROELBOB
  • Low-Code/No-Code
  • IT as Code
  • More
    • Application Performance Management/Monitoring
    • Culture
    • Enterprise DevOps

Home » Blogs » DevOps Practice » Focus on High-Level Policy Requirements to Accelerate Network Processes for DevOps

High-Level Policy Requirements to Accelerate Network Processes DevOps

Focus on High-Level Policy Requirements to Accelerate Network Processes for DevOps

By: Chiara Regale on July 25, 2019 1 Comment

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.

Related Posts
  • Focus on High-Level Policy Requirements to Accelerate Network Processes for DevOps
  • SRE Vs. DevOps: The Wrong Question?
  • 5 Reasons DevOps Needs NetDevOps
    Related Categories
  • Blogs
  • DevOps Practice
  • Doin' DevOps
  • Enterprise DevOps
    Related Topics
  • command line interfaces
  • DevNetOps
  • DevOps networking
  • IBN
  • Intent-Based Networking
  • software-defined networks
  • virtual networking
Show more
Show less

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.

DevOps Connect:DevSecOps @ RSAC 2022
Figure 1: The CLI management model and box-by-box management, in general, do not facilitate DevOps processes, which require higher level policy specifications and requirements. DevOps requires the automation of such policy analysis and verification.

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).

Figure 2: A sample policy query is constructed in the top bar, as the IBN platform shows a number of available paths between data centers that map to the policy requirements.

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

Filed Under: Blogs, DevOps Practice, Doin' DevOps, Enterprise DevOps Tagged With: command line interfaces, DevNetOps, DevOps networking, IBN, Intent-Based Networking, software-defined networks, virtual networking

Sponsored Content
Featured eBook
The 101 of Continuous Software Delivery

The 101 of Continuous Software Delivery

Now, more than ever, companies who rapidly react to changing market conditions and customer behavior will have a competitive edge.  Innovation-driven response is successful not only when a company has new ideas, but also when the software needed to implement them is delivered quickly. Companies who have weathered recent events ... Read More
« How IoT Security Risks Derailing Robotics
Stackery Smooths AWS Serverless Integration for DevOps »

TechStrong TV – Live

Click full-screen to enable volume control
Watch latest episodes and shows

Upcoming Webinars

Continuous Deployment
Monday, July 11, 2022 - 1:00 pm EDT
Using External Tables to Store and Query Data on MinIO With SQL Server 2022
Tuesday, July 12, 2022 - 11:00 am EDT
Goldilocks and the 3 Levels of Cardinality: Getting it Just Right
Tuesday, July 12, 2022 - 1:00 pm EDT

Latest from DevOps.com

Rust in Linux 5.20 | Deepfake Hiring Fraud | IBM WFH ‘New Normal’
June 30, 2022 | Richi Jennings
Moving From Lift-and-Shift to Cloud-Native
June 30, 2022 | Alexander Gallagher
The Two Types of Code Vulnerabilities
June 30, 2022 | Casey Bisson
Common RDS Misconfigurations DevSecOps Teams Should Know
June 29, 2022 | Gad Rosenthal
Quick! Define DevSecOps: Let’s Call it Development Security
June 29, 2022 | Don Macvittie

Get The Top Stories of the Week

  • View DevOps.com Privacy Policy
  • This field is for validation purposes and should be left unchanged.

Download Free eBook

Hybrid Cloud Security 101
New call-to-action

Most Read on DevOps.com

What Is User Acceptance Testing and Why Is it so Important?
June 27, 2022 | Ron Stefanski
Rust in Linux 5.20 | Deepfake Hiring Fraud | IBM WFH ‘New No...
June 30, 2022 | Richi Jennings
Chip-to-Cloud IoT: A Step Toward Web3
June 28, 2022 | Nahla Davies
DevOps Connect: DevSecOps — Building a Modern Cybersecurity ...
June 27, 2022 | Veronica Haggar
The Two Types of Code Vulnerabilities
June 30, 2022 | Casey Bisson

On-Demand Webinars

DevOps.com Webinar ReplaysDevOps.com Webinar Replays
  • Home
  • About DevOps.com
  • Meet our Authors
  • Write for DevOps.com
  • Media Kit
  • Sponsor Info
  • Copyright
  • TOS
  • Privacy Policy

Powered by Techstrong Group, Inc.

© 2022 ·Techstrong Group, Inc.All rights reserved.