You might have read about SDN technologies, such as those in Microsoft Windows Server 2012 R2 Hyper-V. SDN has the ability to deliver a network that is optimized for application workloads with varying communication needs.
You might have read about software-defined networking (SDN) technologies, such as those found in MicrosoftR2 Hyper-V, which can provide a way for tighter integration between applications and the network. The goal of SDN is to have a network that is aware of and that adjusts to the needs of different applications, through software. SDN has the ability to deliver a network that is optimized for application workloads with varying communication needs. In an SDN world, varied applications, such as Microsoft Lync or SQL Server, can deliver the best network performance possible, regardless of the traffic characteristics of each.
For example, let’s say you have Microsoft Lync running in your environment. Lync traffic has several unique characteristics. First, most Lync communications occur in real time, so traffic can be sensitive to network latency. Second, those interactions run over long periods, as users communicate on voice or video chats. Finally, most Lync traffic is “north-south”; that is, Lync traffic traverses multiple layers of networking equipment, potentially from a variety of vendors.
As a result, many organizations implement network quality of service (QoS) to ensure that Lync-related traffic is prioritized across the networks that connect Lync servers to their clients. But configuring and maintaining QoS across multiple network devices (potentially running on different vendor products) between servers and various Lync clients (including those running on mobile devices) can be complex. Ideally, you want your applications—in this case, Lync clients and servers—to be able to interface and communicate with your network. And you want the network to respond to real-time communication needs, be it by dynamically adjusting QoS configurations or by adjusting other network characteristics, to maintain a high-quality end-user experience.
That is the promise of application-centric SDN: tighter integration between the network and the applications that use it. Implied in this picture is good interoperability between the software that maintains the network and the various vendor products that sit in between the Lync traffic. Thus, standards-based interoperability is another important capability of SDN that makes this kind of interaction possible.
As I mentioned in the previous example, different applications have different requirements as they pertain to network traffic. A client-server application such as Lync or SharePoint has different network interactions (primarily north- and southbound and likely across physical networks composed of varying vendor devices) than a SQL Server back-end database communicating with a set of front-end application or web servers across a virtual network (east- and westbound traffic). A good description of how applications drive the network is captured in the blog post Applications: The Reason We Have Infrastructure. Historically, networks—especially physical networks—have been too brittle, incompatible and difficult to configure to accommodate these kinds of dynamic and varied workloads in real time. But with the advent of SDN, we are getting closer to that reality.
Microsoft is in a unique position to deliver on this as well. Since it has a full stack of solutions—from hypervisor to applications—Microsoft can deliver north- and southbound management through support in its products of industry standards such as OpenFlow, and for east-west traffic between applications such as SQL Server and applications that use Hyper-V virtual networking.
Of course, as I’ve discussed, much of this story, primarily for northbound and southbound traffic, relies on all devices on the network being able to work in concert to implement a software driven network. This is where vendor interoperability of SDN standards comes into play—and where Microsoft has been taking a leading role by participating in initiatives such as the Open Daylight and Open Networking working groups and Cisco’s Application Centric Infrastructure (ACI) initiative.
At the end of the day, if your applications can communicate their needs in real time to your network fabric—both physical and virtual—then users have a better experience. This is true regardless of whether they are on a mobile phone, participating in a Lync video chat, or on a PC on the company network, talking to a SharePoint server in Microsoft Azure. To learn more about SDN, look at the Software-Defined Networking Solutions page at http://www.microsoft.com/en-us/server-cloud/solutions/software-defined-networking.aspx. To learn more about Cisco’s ACI initiative and Microsoft’s participation in it, check out this solution brief and this keynote.