Cisco launched its Cloud Native SD-WAN (CN-WAN) project in a move to more tightly integrate an organization’s network operations and DevOps team to bolster the deployment of Kubernetes-managed microservices.

The basic gist of CN-WAN is to allow DevOps teams to lay out the WAN needs of the microservices that they deploy in a Kubernetes-managed cluster and for the network operations folks to automatically import those needs into their dynamic WAN optimizations. Vijoy Pandey, CTO and cloud platform and software VP at Cisco, explained in a blog post that the project is about “CN-WAN maps Kubernetes application attributes to SD-WAN network capabilities to automatically optimize the application performance over the WAN.”

The CN-WAN architecture includes a Kubernetes operator that is deployed in the cluster and designed to run and manage the deployed service; a reader on the SD-WAN side that taps the service registry to find out how Kubernetes is exposing the services and WAN metadata coming from the operator; and an adaptor on the SD-WAN side that maps the metadata into the SD-WAN policies programmed by the network operations team in the SD-WAN controller.

"It's about making SD-WAN application aware and doing it in such a way that it's proactive and that it's part of the application definition in a Kubernetes environment," Pandey added as part of an interview with SDxCentral.

Cisco demonstrated the platform by establishing two tunnels in its Viptela SD-WAN product. Those tunnels mimicked the behavior of the public internet link and a business internet link. Most of the traffic between the user and the cluster was routed through the public internet tunnel, but the more latency-sensitive video traffic was automatically routed through the business internet tunnel.

Pandey explained that the network operations teams that are in charge of programming SD-WAN policies do not typically work that closely with the DevOps teams that are in charge of overseeing an organization’s Kubernetes or cloud-native applications.

“We believe there is an opportunity to pair the declarative nature of Kubernetes with the programmable nature of modern SD-WAN solutions,” Pandey writes. “This allows us to not only improve connectivity toward the Kubernetes cluster but also to simplify and automate the consumption of SD-WAN capabilities by cloud-native applications.”

The CN-WAN project is also more outward looking than the current Container Network Interface (CNI) project that is already part of the Cloud Native Computing Foundation (CNCF). CNI is an open source tool for regulating communications within a Kubernetes environment, and is the basis for a number of products like Calico, Flannel, and Weave.

Pandey explained that CNI works well within that insular Kubernetes environment, but it "breaks down in a brownfield deployment" outside of the application layer. He said this includes connections to virtual machines (VMs), bare metal, or into a branch or enterprise environment. "If you go outside of the Kubernetes environment, then sorry you are out of luck," Pandey added.

The launch also referenced Cisco’s deal earlier this year with Google to develop an application-centric, multi-cloud network fabric to allow customers to extend SD-WAN orchestration and management to the cloud. That work uses Cisco’s SD-WAN Cloud Hub with Google Cloud to apply consistent service level agreements, security policies, and compliance data to applications and enterprise networks.

Pandey noted that move showed the ability to automate the “tasks needed to deliver a better application experience over the SD-WAN. The ideas highlighted in that post can apply to any workload, including cloud-native workloads.”