Simplifying the DevOps and NetOps Journey using Cisco SD-WAN Cloud Hub with Google Cloud

Contributing Authors: Alberto Rodriguez-Natal, Fabio Maino, Steve Wood (Cisco), Alex Lo, Ashish Verma, and Ines Envid (Google Cloud)

Cisco and Google Cloud have partnered to bridge cloud applications and enterprise networks by creating the new Cisco SD-WAN Cloud Hub with Google Cloud. This solution, built around Cisco SD-WAN technology and Google Cloud, simplifies the NetOps and DevOps journey by automating the allocation of SD-WAN network resources to meet application requirements.

Modern enterprise applications are composed of multiple services deployed across on-premise and cloud environments. NetOps and DevOps teams maintain the infrastructure that hosts, connects, and delivers these services. The goal of these teams: optimize the application experience. But due to the complexity of the infrastructure and the dynamism of application flows, this can be challenging. Each time a new application is deployed, the NetOps team must collect the application requirements from the DevOps team and render them into the appropriate network policy.

In this post we look at how Cisco SD-WAN Cloud Hub with Google Cloud simplifies workflow for DevOps and NetOps, by automating the tasks needed to deliver a better application experience.

Here we focus on the benefits brought by the solution in terms of automation. There are some benefits that we don’t cover in this article but are also part of the solution, such as the improved security and segmentation, the enhanced multi-cloud operation, and how Cisco SD-WAN Cloud Hub can enable traffic steering through the Google Cloud backbone network.

How DevOps Will Use Cisco SD-WAN Cloud Hub with Google Cloud

DevOps teams are interested in what the network can do for their application, rather than in how it is done. From their perspective, the network is a component meant to support specific application demands. To that end, DevOps will focus on properly classifying services according to certain traffic profiles, for instance Video Streaming or VoIP. These profiles are agreed on beforehand with NetOps, and allow DevOps to express the networking needs of the services. DevOps leaves it to NetOps to best configure the network to handle each profile.

In our new solution, the DevOps team uses Google Cloud Service Directory to publish the traffic profile that best represents the network traffic generated by a given application. They can use different traffic profiles for different services, as needed. The integration of Service Directory with Google Cloud Identity and Access Management (IAM) ensures that only those in the DevOps team with the appropriate permissions can modify the traffic profile for a service.

For example, DevOps and NetOps may agree that the services can be classified according to four profiles: standard, data, streaming and conferencing. The DevOps then use Service Directory to associate the following metadata to each service deployed: “traffic: standard”, “traffic: data”, “traffic: streaming”, and “traffic: conferencing”. (The metadata used here is an example to illustrate the flexibility of the solution; different teams may define different profiles.)

Let’s say that the DevOps team is deploying two services with different networking needs. They want to make sure that the traffic for each is properly handled in the SD-WAN. One service is a heavy-load database backup application, with high bandwidth requirements, while the other is a screen sharing service, not only sensitive to latency but also to packet loss. Following the metadata convention agreed with the NetOps team, the DevOps team marks these services as “traffic: data” and “traffic: conferencing”, respectively.

How NetOps Leverages the Solution

The NetOps team, for its part, has a deep knowledge of the network and can efficiently optimize it to meet application requirements. The NetOps team uses Cisco vManage (Cisco’s centralized SD-WAN management platform) to program detailed network policies that map how each traffic profile should be rendered over the SD-WAN.

The NetOps team may decide to configure policies that specify that traffic with the profile “standard” should go through a best effort tunnel, that “data” should go through a high bandwidth tunnel, and that “streaming” and “conferencing” should go through low latency tunnels. The NetOps team can further fine tune the policies to specify that traffic for “conferencing” services should go, when possible, through highly-reliable links over the Google Cloud backbone to minimize packet loss.

Thanks to the integration with Service Directory, vManage can discover in real-time an application’s characteristics and its networking needs. vManage, by constantly monitoring Service Directory, acts whenever new relevant information becomes available. For instance, as soon as the database backup service is deployed, vManage automatically retrieves the associated metadata via Service Directory and dynamically renders the network policy defined by the NetOps team. In this example, the rendered network policies steer the database backup traffic through a high-bandwidth SD-WAN path. Likewise, a conferencing application, say the aforementioned screen-sharing service, would see its traffic steered to the Google Cloud backbone.

In this way the network automatically adapts, in real-time, not only to new applications, but also to changes in application requirements or changes in existing traffic profiles. The most relevant and effective network policies are always enforced and specifically tailored for each service. This greatly simplifies operations for both NetOps and DevOps teams, which now only need to make sure that the intended application profiles and network policies are in place. Service Directory and vManage coordinate to dynamically render the most effective network optimizations.

The integration of Cisco vManage and Google Cloud Service Directory leads to an improved application experience and more efficient use of SD-WAN resources.

Additional automatic traffic steering is also a part of the solution, thanks to the automatic aggregation of data about applications, obtained via Service Directory, correlated with vManage’s detailed, real-time view of network infrastructure. For instance, prior to this integration, minimal losses on a high-bandwidth link may not trigger special actions on regular SD-WAN operation. With this solution in place, vManage, knowing that there is traffic over this link that belongs to a “conferencing” application, might automatically steer that traffic through an alternate, non-lossy link. Similarly, knowing that “standard” applications are not sensitive to small losses, vManage can take advantage of the bandwidth just made available to automatically allocate flows for “standard” applications over the lossy link.

To conclude, Cisco SD-WAN Cloud Hub with Google Cloud leverages Cisco SD-WAN and Google Cloud Service Directory to simplify the journey of the NetOps and the DevOps teams, automating the allocation of SD-WAN network resources to match applications’ demands, optimizing the application experience. All without disrupting the continuous flow with which applications are developed, deployed and supported.

To learn more: