The move to continuous integration/continuous deployment (CI/CD) and agile development methodologies means that application development now requires network IT operation teams (NetOps) and security operation teams (SecOps) to work together, which puts increased stress on developers and engineers.

Add heterogeneous computing environments to the mix, and it’s no wonder that the role of application delivery and security within DevOps has never been more onerous. Selecting an application delivery solution that maximises automation and integrates into an existing DevOps environment is critical.

Here are four reasons why application delivery is critical to supporting DevOps.

Production-ready automation
CI/CD and agile development methodologies require IT experts from different domains, (i.e., application, storage, network security, application delivery) to deploy new application services and their associated policies. Traditionally, they’ve had to invest in long, tedious provisioning and programming tasks that are often repetitive and require specific domain expertise to execute.

In a DevOps-driven world, this is no longer possible. IT requires workflow automation so that even non-technical experts can develop and craft application delivery and security workflows. According to Radware research, over half (53%) of organisations don’t integrate application protection into CI/CD processes.

This is why IT operations require an evolution, transitioning from simple scripts to standard-based, production-ready modules. The goal? To enable anybody from different teams to deploy and manage services regardless of the domain expertise he or she possesses.

Automated ADC and security
The marketplace for application delivery and security solutions is as diverse as its capabilities. Selecting one that integrates with an application provisioning and deployment solution, such as Ansible, is critical to enabling end-to-end automation.

Traditionally, deploying a new application delivery service has meant writing and managing a monolithic, gargantuan script to automate the workflow. Each application deployment requires a different workflow, and thus, a different script. DevOps requires these monolithic codes to be broken into discrete operations to speed time to development and deployment.

Underlying application delivery and security services that support these applications are no exception to this rule. An enterprise-grade ADC should provide pre-defined/production-ready modules and integration with DevOps orchestration tools to allow non-technical users to spin up and deploy application and security services.

Traditionally, if an error occurs, a review and QA of the code would be required. In a module-based world, errors become more transparent and segmented. For example, if only the application security policy is incorrect, the problem can be identified, fixed and only the security policy rerun, versus the entire script-based workflow.

Reuse and repurpose
Production-ready modules provide the ability to reuse and repurpose. If a particular module, such as the application security module, requires an update, SecOps can make that update, create a subversion if necessary and apply it to other application workflows. Changes are isolated to the specific module and don’t impact other aspects of the workflow.

Finally, an application owner, versus an ADC expert, can make these changes to the application security module or other modules. For example, while application servers and security policies can reside with the application owner, VLAN operations might be a network administrator’s responsibility. Now, a single person can manage these usually disparate responsibilities, thereby saving time to market.

This modularised approach also means switching from staging to production and back seamlessly. Changes to workflow parameters made within a staging environment can be pushed to production following staging. These capabilities support CI/CD processes by minimising human errors and reducing downtime.

Enterprise-grade ADC capabilities
Finally, any application delivery solution must combine ease of use with advanced application delivery capabilities, such as optimising Layer 7 load balancing deploying and managing application security policies. This further enhances the capabilities of any DevOps orchestration tool.

Cisco and Google Extend Their Technology Alliance

Cisco Systems and Google announced an extension of their existing technology partnership aimed at tighter integration between Cisco’s software-defined wide area network (SD-WAN) platform and Google’s cloud infrastructure. The collaboration spans multiple layers of the stack—from Kubernetes orchestration to cloud management tooling—and points toward a future in which network provisioning becomes a fully programmable, API-driven activity embedded in standard DevOps workflows.

A key milestone in this expanded alliance was the planned availability of Cisco SD-WAN software running on Google Anthos, Google’s Kubernetes-based hybrid and multi-cloud platform. Anthos is notable because it can be deployed across public clouds and on-premises environments under a consistent management model—a property that makes it attractive for enterprises managing heterogeneous infrastructure.

Why SD-WAN Is Moving to the Cloud

John Apostolopoulos, Vice President and CTO of the Intent-Based Networking Group at Cisco, cited the COVID-19 pandemic as an accelerant for cloud-hosted SD-WAN adoption. With remote work surging, many organizations reconsidered their reliance on traditional VPN infrastructure and began evaluating SD-WAN as a more scalable, flexible alternative.

Crucially, Apostolopoulos noted that a growing share of new SD-WAN deployments are expected to land in public cloud environments rather than in on-premises data centers. This shift has direct consequences for how networking services are consumed: instead of configuring physical routers and switches, teams increasingly invoke SD-WAN capabilities through cloud-resident APIs.

The Convergence of NetOps and DevOps

Perhaps the most significant organizational implication of this trend is the narrowing gap between NetOps (network operations) and DevOps (software development and operations) disciplines. Historically, these two teams have operated largely in silos. Developers and application teams would submit tickets and wait days or weeks for network changes to be manually provisioned by dedicated networking staff.

As SD-WAN services become software-defined, API-accessible resources on cloud platforms, DevOps teams gain the ability to programmatically request and configure network connectivity as part of their deployment pipelines—the same way they already provision compute or storage. Apostolopoulos acknowledged that networking specialists will remain essential for performance optimization and complex design decisions, but the era of weeks-long manual provisioning cycles is coming to an end.

Centralized Management Across Multiple Clouds

Cisco’s strategic bet is that enterprises would rather extend a familiar, consistent enterprise networking layer across multiple clouds than adopt and integrate fragmented, cloud-native networking services from each hyperscaler independently. The proposed value proposition is straightforward:

• Consistency: A single management console backed by a uniform API surface across AWS, Google Cloud, Azure, and on-premises environments.
• Reduced integration overhead: Avoiding the engineering cost of stitching together heterogeneous networking and security controls from multiple vendors.
• Integrated security: Cisco positioned its security portfolio as a natural complement to SD-WAN, with the goal of delivering networking and security controls through the same management plane.

Apostolopoulos framed this as a total-cost-of-ownership argument: while Cisco may not always offer the lowest per-device price, the cumulative integration cost of multi-vendor networking and security stacks can quickly erode any per-unit savings.

Implications for DevOps Teams

For DevOps practitioners, this partnership signals several practical shifts worth tracking:

• Infrastructure-as-Code for networking: SD-WAN APIs on cloud platforms make it feasible to define network topology and policy in code, version-control it, and deploy it through CI/CD pipelines alongside application code.
• Faster release cycles: Eliminating manual NetOps handoffs removes a traditional bottleneck in application deployment workflows.
• Shared observability: Cloud-hosted SD-WAN management consoles can expose telemetry that both NetOps and DevOps teams consume, enabling joint troubleshooting and SLO accountability.
• Security as code: Integrated security policies tied to the SD-WAN layer can be applied programmatically, reducing the gap between security intent and enforcement.

The Bigger Picture: Networking as a Software Service

The Cisco–Google alliance is one visible data point in a broader industry movement: the gradual transformation of enterprise networking from a hardware-centric discipline into a software-driven, API-first practice. The Anthos integration illustrates how Kubernetes—originally a container orchestration platform—is becoming an organizing layer not just for compute workloads but for network and security policy as well.

Whether this trajectory leads to the full absorption of NetOps roles into DevOps teams or to a redefined, more software-fluent network engineering function remains an open organizational question. What is clear is that enterprises maintaining static, manually operated network infrastructure will find it increasingly difficult to match the deployment velocity and agility expected in cloud-native application environments.

The Network Is Now the Runtime

In software delivery, innovation moves fast — but nothing actually moves unless the network can handle it. For businesses adopting DevOps practices, network agility is no longer a nice-to-have: it is a prerequisite for organizational agility as a whole.

Ed Warnicke, Distinguished Consulting Engineer at Cisco Systems Inc., framed the challenge this way:

“The truth is, there’s a lot of work that goes into making the network invisible and ubiquitous for people. In particular, one of the challenges that we see arising as the world moves more cloud native, as the microservices get smaller, as the shift happens toward serverless, as Kubernetes is coming on with containers, is that the network is really becoming the runtime — and that runtime has the need to scale and perform like it never has before.”

Ed Warnicke, Distinguished Consulting Engineer, Cisco Systems Inc.

In other words, the network is no longer a passive pipe sitting beneath application logic. As workloads decompose into smaller microservices, containers, and serverless functions, the network itself becomes an active part of the execution environment — one that must meet the same reliability, scalability, and automation expectations as any other piece of infrastructure.

DevOps and NetOps: Why They Need Each Other

DevOps teams want the network to be invisible. They need it to be fast, reliable, and easy to consume — but they do not want to manage low-level networking details when their focus is on deploying and iterating software. This is not a criticism of network engineers; it reflects a healthy division of responsibility.

However, invisibility creates a new problem. As Warnicke put it: “The more invisible the network is, the more visibility you need when things go wrong.” When a microservice-to-microservice call fails, or latency spikes unexpectedly inside a Kubernetes cluster, the network team needs tools capable of deep inspection — per-flow tracing, real-time telemetry, and contextual diagnostics — not just ping and traceroute.

This creates a two-way dependency:

• DevOps needs NetOps to provide a network that scales automatically, exposes clean APIs, and stays out of the critical path of software delivery.
• NetOps needs DevOps to communicate what networking primitives and APIs are actually useful, so network engineers can write code and configure systems that serve real application requirements.

Without this dialogue, network tooling risks evolving in isolation — technically sophisticated but poorly matched to how modern applications are built and deployed.

Open-Source Projects Bridging the Gap

FD.io (“Fido”)

One project helping to close the distance between networking and DevOps practices is FD.io (pronounced “Fido”), a Linux Foundation collaborative project. FD.io is a high-performance, extensible I/O services framework designed for data plane workloads.

Key characteristics of FD.io include:

• Plugin-based extensibility: New functionality can be added by dropping plugins into a directory, without rebuilding the entire system. This aligns with DevOps principles of modular, composable infrastructure.
• High throughput at low latency: FD.io is built around VPP (Vector Packet Processing), which processes multiple packets per CPU instruction rather than one at a time, enabling wire-speed performance in software.
• Network visibility: Despite abstracting away complexity for application developers, FD.io provides the deep visibility that network operators need when diagnosing failures in distributed systems.

Beyond FD.io, the broader open-source community has produced tools capable of per-customer, per-flow network tracing — critical capabilities when debugging latency or connectivity issues in environments with thousands of concurrent microservice interactions.

What This Means for DevOps Engineers

For DevOps practitioners, the convergence of networking and DevOps tooling has several practical implications:

• Network-as-Code: Just as infrastructure is managed through code (Terraform, Ansible, Pulumi), network configuration increasingly follows the same pattern. Engaging with NetOps teams to expose network resources through well-designed APIs is a shared responsibility.
• Observability extends to the network: Distributed tracing, service mesh telemetry (e.g., Istio, Linkerd), and eBPF-based tools are making network-layer observability a first-class concern for DevOps teams, not just network engineers.
• Cloud-native networking demands cloud-native operations: Kubernetes CNI plugins, service meshes, and software-defined networking solutions require DevOps teams to understand at least the basics of how network policies, ingress, and east-west traffic function in containerized environments.
• APIs matter: As Warnicke noted, teams must actively work to support existing APIs and take advantage of new features as they become available. Staying current with networking APIs — whether from cloud providers, CNI implementations, or open-source projects — is increasingly part of the DevOps skill set.

Collaboration Is the Path Forward

The key message from Warnicke’s perspective is that neither DevOps nor NetOps can solve the challenges of modern distributed systems in isolation. Network operations teams must proactively engage with development and operations engineers to understand what they need. DevOps teams, in turn, benefit from learning enough networking fundamentals to have productive conversations about performance, reliability, and observability requirements.

Open-source projects like FD.io, along with the broader Linux Foundation networking ecosystem, are providing neutral ground where both communities can contribute, share tooling, and align on common standards — without being locked into any single vendor’s roadmap.

“You have to make sure you’re supporting all the stuff that’s there, and you have to work to take advantage of new features in existing APIs.”

Ed Warnicke, Cisco Systems Inc.

As the network continues its transition from passive infrastructure to active runtime, the organizations that invest in cross-team collaboration and open-source tooling will be the ones best positioned to scale.

Original source: SiliconAngle.com. Interview recorded at the Open Source Summit, Los Angeles. theCUBE is SiliconAngle’s mobile livestreaming studio.

Overview

F5 Networks released the results of a survey comparing the views of more than 850 NetOps and DevOps IT professionals on their disciplines, collaboration practices, and attitudes toward automation and multi-cloud deployments. The conventional wisdom has long painted NetOps and DevOps as adversarial groups with incompatible goals. The survey data tells a more nuanced story: the two groups share more common ground than the “us vs. them” narrative suggests, but specific friction points around pipeline access and skill gaps are quietly driving the fragmentation of infrastructure across multiple cloud providers.

Key Survey Findings

Mutual Respect for Each Other’s Priorities

More than three-quarters of respondents in both groups said they believe the other function is prioritizing the right things within IT. This level of cross-functional respect is significant: it signals a shared understanding of broader organisational goals and a foundation for deeper collaboration. Deployment frequency was also a point of agreement, with 70% of DevOps and 74% of NetOps respondents indicating satisfaction with the pace at which applications and services are being delivered.

Shared Support for Automation

Both groups rated pipeline automation as important, though with slightly different levels of enthusiasm. On a 5-point scale, DevOps respondents gave automation an average significance rating of 4.0, while NetOps rated it 3.5. Critically, both groups reported higher confidence in application reliability, performance, and security when the production pipeline was more than 50% automated. This is a meaningful data point: it suggests that increasing automation is not just a DevOps preference but a broadly held belief about how to build more dependable systems.

Friction Over Pipeline Access

The clearest point of divergence concerns how much access DevOps should have to production resources. Forty-five percent of DevOps respondents believe they should have access to at least 75% of the production pipeline. Only 31% of NetOps respondents agreed with granting DevOps that level of access. This 14-point gap reflects a structural tension: DevOps teams need broad access to move fast, while NetOps teams carry responsibility for security, availability, and performance — and are therefore more cautious about permissions.

Left unresolved, this misalignment creates organisational drag. Processes that should be streamlined stall, and application delivery timelines slip — directly impacting business outcomes in an environment that increasingly depends on rapid digital delivery.

Pipeline Access Gaps Are Fuelling Multi-Cloud Sprawl

The access friction has a concrete downstream effect: it is pushing DevOps teams toward cloud solutions outside the traditional IT stack. Sixty-five percent of DevOps respondents said they are influenced “a lot” or “some” toward adopting cloud solutions by the level of automation and self-service access available in the pipeline. On the NetOps side, 44% said DevOps’ use of external cloud technologies affects their willingness to grant pipeline access “some,” with an additional 21% saying it affects them “a lot.”

The result is a self-reinforcing cycle: limited pipeline access leads DevOps to adopt cloud-based workarounds, which increases NetOps’ caution about permissions, which further limits access and drives even more cloud adoption. The end state is a multi-cloud environment that evolves organically rather than by design — making application delivery, scaling, and security progressively harder to manage.

Bridging NetOps and DevOps: What the Data Suggests

The survey results collectively point to automation and self-service capabilities as the most productive area of shared investment. Both teams want more of it; both teams report better outcomes when it is in place. The challenge is agreeing on the governance model that determines who controls what — and to what extent.

Skill gaps compound the problem. DevOps respondents rated their own skills at 3.6 out of 5 in terms of meeting their job function requirements. NetOps rated themselves slightly lower at 3.4. Neither score is alarming in isolation, but in the context of rapid cloud adoption and increasing infrastructure complexity, confidence gaps on both sides can slow the adoption of the very automation tools that would benefit everyone.

Practical Implications for Engineering Teams

• Define pipeline access policies jointly. The data shows that NetOps and DevOps disagree on access levels — but both groups respect each other. This is the right environment for a structured conversation about role-based access controls (RBAC) and clear ownership boundaries within CI/CD and production pipelines.
• Treat automation as a shared goal, not a DevOps project. NetOps teams that score automation at 3.5 out of 5 are not opposed to it. Framing automation initiatives as cross-functional efforts — with NetOps involved in design and governance — is more likely to build consensus than presenting them as developer-led mandates.
• Address multi-cloud sprawl proactively. Unplanned multi-cloud adoption driven by access limitations is harder to secure and govern than planned multi-cloud architectures. Teams should assess whether current access friction is a root cause of cloud sprawl before adding more cloud providers.
• Invest in cross-functional training. Skill gaps in both groups are real. Certification programs, shared labs, and cross-team training reduce the knowledge silos that reinforce the NetOps/DevOps divide.
• Establish shared KPIs. Deployment frequency, application reliability, and security incident rates are metrics both teams care about. Shared dashboards and shared accountability help align incentives.

Context: Why This Still Matters

Although this survey was conducted in 2017, the underlying tensions it identifies have not disappeared. If anything, the proliferation of Kubernetes, service meshes, cloud-native networking, and platform engineering has made the NetOps/DevOps boundary more complex, not less. The debate over who owns the network layer in a containerised, multi-cloud environment is an active one in most large engineering organisations. The finding that both groups broadly support collaboration — but diverge on access — remains a useful diagnostic frame for teams trying to understand why their DevOps transformation is stalling.

Source

Survey data and executive commentary sourced from an F5 Networks press release published via Business Wire, August 2017. The full companion report with methodology details was referenced in the original announcement but is not linked here.