Covering Disruptive Technology Powering Business in The Digital Age

Home > Archives > News > Cisco’s CN-WAN a Bridge Between DevOps and NetOps
Cisco’s CN-WAN a Bridge Between DevOps and NetOps
August 25, 2020 News


In many instances today, enterprises are struggling to link their DevOps, who are in charge of the configuration of their containerised applications and their NetOps who maintain the connectivity of their network, especially through SD-WAN.

Cisco saw the need to build a bridge between the two and with their latest announcement last week in the KubeCon Europe 2020, the company introduced the Cloud-Native SD-WAN (CN-WAN), which aims to integrate business operations running in the container platform Kubernetes and the SD-WAN technology.

“We believe there is an opportunity to pair the declarative nature of Kubernetes with the programmable nature of modern SD-WAN solutions”, Cisco said in a blog. CN-WAN, also an open-source project, illustrates how SD-WAN solutions can be integrated with the Kubernetes ecosystem to become aware of the needs of cloud-native applications.

CN-WAN consists of three components that optimise SD-WAN in the microservices running within the Kubernetes platform, helping both the DevOps and NetOps in implementing a better application service. In the blog, Cisco demonstrated how it would function within a cloud-native video conferencing application which contains microservices such as voice, video, slides, chat, etc.

A CN-WAN integration is able to improve the end-user experience of the video conferencing app by using three components running in both the DevOps and NetOps:

  • The first one is the CN-WAN Operator running in Kubernetes, which monitors externally exposed services deployed in the container platform. DevOps can then use connotations to easily specify the type of traffic that the SD-WAN can expect for that particular service. For example “”. With this, CN-WAN Operator extracts the externally exposed IP address and port for the services as well as the associated WAN metadata and makes it all available through an external service registry.
  • CN-WAN reader, the second component, will now connect to the service registry to learn about how Kubernetes is exposing the services and their associated WAN metadata, as extracted by the CN-WAN operator. The CN-WAN Reader keeps track of updates regarding the services exposed and the metadata.
  • When it detects new or updated services or metadata, it sends a message towards the third component, the CN-WAN Adaptor so SD-WAN policies can be updated. The Adaptor is actively listening for updates from the CN-WAN Reader and connects with a given SD-WAN controller to translate the service metadata into SD-WAN policies.

As the resource demands of each microservice may vary, this approach would help improve network traffic performance (and ultimately, the performance of the whole application) by assigning the required bandwidth or latency based on the specific requirements of each microservice.

CN-WAN would greatly benefit businesses by building a bridge between their DevOps and NetOps, which Cisco described as “ships in the night” before the introduction of CN-WAN. This will integrate the Kubernetes containerisation platform and the SD-WAN technology so that applications are easily deployed, updated automatically and will reduce the manual coordination between DevOps and NetOps, creating a more dynamic application experience across the business WAN connections.