Software Defined Networking (Sdn): Double-Clicking Into Our Point Of View

AWS · July 31, 2013

A couple of weeks ago we spoke about our approach to Software Defined Networking (SDN) - an approach that is open and extensible, driven by experience and most importantly, one that lets you leverage your existing investments.

Over the last few months, we have also spoken in detail about this with thousands of customers at MMS, Interop, TechEd North America and TechEd Europe . Over the course of these conversations, we realized a few common themes emerging:

Confusion around means of realizing SDN that overshadow the benefits offered
Questions around opportunities for server and networking admins to enhance their careers
Non-traditional players like Microsoft will have significant roles to play

We felt this blog would be a good platform to discuss these in more detail since we are sure a lot of you have the same questions. Lets double-click in.

Means of realizing Software Defined Networking:

SDN does not mean that you rip and replace your existing network devices and replace them with new SDN aware devices. In most cases, the cheapest and most flexible network infrastructure is the one you already own. If your network scales-up to meet your needs with a manageable OPEX, networking as you know it will continue to exist and you shouldnt worry about jumping on the bandwagon just because everyone is talking about SDN.

With that said, networking is widely acknowledged to be the final piece of the puzzle requiring simplification in order to meet the agility and flexibility demands of modern datacenters. Centralized provisioning, management and monitoring of compute and storage is very common today. Sadly, networking often remains stuck in the past - inflexible, hard wired and complex. This is the source of many of todays most troublesome and difficult problems responsible for service downtimes and application slowdowns. These are problems experienced by many large customers not just those operating at cloud scale running tens of thousands of hosts. The complexity of the problems arising is beyond what can be manually fixed and/or monitored.

These real-world problems drove the need for a software defined solution to manage networking. The two approaches taken in large datacenters to do this are:

Isolated virtual networks/network overlays. These sit on top of the physical network and are abstracted from the underlying networking hardware. Since the virtual networks are software defined, it allows admins to create and manage them from a centralized location depending on the needs of the application, templatize it and replicate it across their datacenters. As a result, management overhead is greatly reduced and a lot of mundane, error prone tasks are automated as a part of virtual network definition. A couple of important points to note here are that customers leverage existing hardware investments and this approach does not require any change to the way applications are written. Microsofts Hyper-V Network Virtualization and VMwares Nicira are solutions that fall within this category.
Centralized controllers. These control the physical network infrastructure directly from a centralized location. This is often paired with an API for programming the network and gives the ability for software to program the network on the fly. This lets software, potentially even applications, dynamically configure the networks depending on current needs. This requires switches and routers to expose these functionalities (Southbound APIs) and a standardized interface for applications to consume them (Northbound APIs). OpenFlow and Cisco One Platform kit are examples of this approach. Since software directly configures the network, it needs to be rewritten to make use of this functionality. Custom applications that run within large datacenters, network diagnostic tools, apps that requires high fidelity connections, etc. are some examples where having such fine grained control will be helpful.

There are other variations of SDN solutions that exist today. But for the sake of simplicity, lets focus on just these two.

As you see in both above mentioned cases, the end goal is the same simplifying networking using the power of software. In one solution the application is aware of the underlying network and controls it using different protocols. In the other solution, the network is abstracted depending on application needs and the complexity is hidden. Windows Server 2012 and System Center 2012 SP1 support and work with both these approaches. As highlighted in previous blog posts, Network Virtualization is built into Windows Server 2012 and customers can use System Center 2012 SP1 to create and manage virtual networks. With the Hyper-V Virtual Switch extensibility, partners like NEC have added functionality to the virtual switch to make it behave like an OpenFlow controller. Additionally applications like Lync are looking at ways to configure the network on the fly to ensure consistent call and video quality.

Opportunities for Server and Networking admins

A common discussion that comes up in this new world of Software Define Networking is the opportunity it creates for Server and Network Admins to enhance their careers. Traditionally both these groups have had well defined boundaries that have worked well for the most part after all, network admins are the backbones of the modern internet that we all take for granted today.

Having said that, there is definitely room for improvement. When applications encounter performance issues, the blame is usually passed around before the actual issue is identified. Identifying and fixing issues are often considered an art with hundreds of manual steps.

We dont have a crystal ball to show us if these pain points will go away with SDN. But all signs are positive and bear good news for the careers of datacenter infrastructure folks and IT organizations in general:

Network Admins grow into network architects SDN helps remove the work from the job of network admins. They spend more time designing/architecting the network to meet the needs of the application as opposed to working on fixing low-value issues. This could include helping their organizations decide the right approach to SDN from the choices that we covered earlier. Additionally, since automation is core to SDN, this helps network admins build a new muscle which spans beyond areas that they have traditionally worked on. In the new SDN world, network admins can expect to frequently use tools such as Windows PowerShell, System Center Orchestrator, System Center Virtual Machine Manager, etc. which were once considered exclusive to Server Admins.
Server Admins will have a better understanding of how the underlying networking fabric is designed. Newer tools will be available that will not only help better diagnose and isolate network issues, but also be able to automatically fix them in many cases. Finally, they will have the flexibility to define abstractions that meets their business needs irrespective of how the underlying physical infrastructure is designed.

Why is Microsoft talking about SDN?

The last topic we wanted to talk about here is the role of companies like Microsoft in the transformation the networking industry is going through. In fact, in the keynote panel at Interop a back in May we had an unlikely combination of executives from Microsoft, VMware (both software companies) and Broadcom (chipset manufacturer) talk about SDN. These arent traditional networking players, so why are they talking about SDN?

In addition to the obvious term software in SDN, and Microsoft being a software company, there is another important trend that should be noticed. As more workloads are virtualized, the virtual switch is becoming the policy edge in networking as opposed to the physical switch. Networking teams work as much with the virtual switch in a heavily virtualized datacenter as they would do with the physical switch. With customers and partners building rich extensions and adding more functionality to the virtual switch, this trend is only going to improve. These non-traditional players will continue playing a significant role in years to come.

Additionally, Microsoft operates some of the largest datacenters in the world where we have faced a considerable number of challenges that many of you see in your datacenters. We onboard over 1000 new customers in Azure datacenters and make tens of thousands of networking changes every single day. Given the paranoia that exists around having every process automated, we have a unique opportunity to bring some of our learnings back into the product that runs both in our datacenters and our customers datacenters.

SDN is a paradigm that is evolving. This is not a change that will happen overnight. This is also not an all-in choice that IT organizations has to take today that locks them in with a specific vendor or a protocol. In fact if we were to write a post about what SDN is not, this will be among the first few points that we will list. There are incumbent players like Cisco and Juniper who are investing heavily in SDN. There are non-traditional players like Microsoft who are taking a fresh look at networking, along with a lot of startups innovating in this space as well. Finally, there are industry consortiums like Open Daylight where some of the players we mentioned above are actively working on defining the direction of SDN.

Just as we discussed in the previous post, with Windows Server 2012, System Center 2012 SP1 and with the additional work we have delivered, side by side with our partners, you have the opportunity to explore the key benefits of SDN for yourselves. Try it out and let us know what you think: