<img height="1" width="1" src="https://www.facebook.com/tr?id=1529264867168163&amp;ev=PageView &amp;noscript=1">
blog_listing_hero_img.jpg

The Future of Software Defined Networking in Windows

windows server 2012
Lately, I have been thinking a lot about networks and connectivity, especially, about how software defined networking is going to change the traditional networking landscape and how SDN fits in with current deployments, either on premises, in a hybrid cloud, or entirely cloud.

Are you familiar with SDN? “Software Defined Networking” does to networks what virtualization has done to hardware, and in fact, it has already begun to do its work:

  • It will abstract away the physical “layer” of cables, routers, switches, and physical IP addresses. With hardware virtualization, the hypervisor took care of working with the actual CPU, memory, buses, and so on, and the operating systems within the virtual machines saw a standard set of virtualized devices—the vagaries of different hardware simply went away. With software defined networking, your Cisco routers and your Juniper switches and your Draytek access points look the same to the operating system, which just sees a bunch of pathways. Your management console is where you define how this abstraction functions, and you get yourself out of any vendor lock in problems you might have suffered in the past.
  • It will allow you to squeeze more functionality and use from your existing investments in networking hardware. You may, and probably do, have plenty of switches and routers deployed, and plenty of internal bandwidth available because a decent portion of your network capacity is unused. By separating the control plane from the data plane, you free up the physical plane to provide more data services to more devices, much like virtualizing operating systems lets you stack multiple machines on one physical host without exhausting the capacity of the host hardware.
  • It will provide the flexibility to move, reconfigure, transform, establish, and make resilient more of your services. Because all of the physical stuff is abstracted away, you can make a virtual network move from a datacenter in Chicago to a datacenter in Hong Kong without touching a single physical setting. You can move links between local networks and other servers with a couple of clicks. And you don’t have to spend hours readdressing network adapters because, again, the virtual network looks the same to the operating system as it always does—the virtual network manager is doing the heavy lifting of directing the actual packets on the physical layers where they need to go.

What does this look like in Windows today? Microsoft has steadily been adding support for virtualized networks in its plain vanilla Hyper-V product that ships in the box in Windows Server 2012 R2, and its System Center management products, including Operations Manager, Virtual Machine Manager, Orchestrator, and so on are fully capable of managing and using virtual networks to automatically deploy machines, fix some problems on their own, and intelligently fail over machines to other hosts for patching or for unplanned maintenance when something goes really hairy.

From the cloud perspective, Microsoft has invested a lot in making sure Microsoft Azure can function as what amounts to an extension of your physical datacenters, through always-on virtual private network (VPN) technology, addressing support that lets you use on premises network addresses and DNS servers, and even the ability to spin up virtual machines in Azure and join them to your on premises domain and have them accessible from your local network—and vice versa, where your Azure VMs can see your local machines and interact with them, too.

So where is all of this SDN goodness going in the future releases of both Windows Server, System Center, and Microsoft Azure?

  • I think we will see a continued movement of SDN features and functionality out of the premium System Center into Windows Server itself, just baked in the box. The ability to manage virtual networks of Hyper-V virtual machines, for instance, including orchestrating failover into Azure while not changing around IP addresses is something that is reserved for System Center now that ought to be in the box, arguably. In addition,I think we will find further customization and extensibility of the Hyper-V virtual switch, which is really an unheralded feature of Hyper-V—with this, all sorts of SDN enhanced scenarios become possible, with greater resiliency and security.
  • I believe we will see Hyper-V network deployment become a series of connections between Hyper-V virtual switches—either from datacenter to datacenter or from datacenter to Azure, but with a better interface and more ability to customize on a virtual port level what is happening. There is no reason an administrator should not be able to customize virtual networks and change their configurations from a single console, even if some of those switches are up in Microsoft Azure. As bandwidth gets cheaper, more and more businesses will run workloads up in the cloud, but there is no reason to lose the control over the data plane that exists with physical on premises networks now. This is an area of evolution, and one that will be interesting to watch, too.
  • In all of Microsoft’s products and services, we will see a focus on enabling complete network provisioning, configuration, and maintenance from end to end, regardless of the physical route and the physical devices used to provide the connectivity. From Windows Setup to failover, expect to be able to define and control the network path for any resource, client, server, network device, or otherwise.
  • We might even see Office 365 come into play here, although that service is generally regarded as one whose infrastructure administrators do not manage. However, it is not hard to envision tighter linking of hybrid Exchange Online and on premises scenarios through some effective virtual routing.