In the early days of IT, networking was straightforward. Every endpoint device had a single Ethernet NIC, connected by a single cable to a single switch port. Network engineers used VLANs to isolate workloads and used IP routing to control traffic between VLANs. Users could connect quite well with applications on servers, and it was good.

Eventually those simple networks needed to become resilient so that they could tolerate single points of failure. It was a simple matter of doubling everything: two NICs, two cables, and two ports on two switches. This change gave rise to the classic core-and-edge network architecture that IT still uses. The network engineer’s job changed hardly at all. It was still good.

When virtualization came along, things became much more complicated. No longer do physical cables connect individual workloads, which now consist of virtual machines (VMs), virtual storage devices, and even virtual network appliances such as firewalls and load balancers. Complicating things further, these workloads can move around on the network without warning, to meet performance and reliability objectives. Cloud computing adds yet another complication, bringing factors such as security, throughput, and latency to network administration.

Suddenly the network engineer’s job is difficult, with every new application requiring hours of design and error-prone manual configuration. Engineers need to make changes to the dozens of routers and switches that make up “the network.” Dealing with workload mobility adds complex coupling between application servers and the physical network, and that coupling brings further opportunity for outage-inducing missteps. It was bad. It is bad. And it needs to change.

Luckily, something new—and good—is at hand. A network architecture approach called software-defined networking (SDN) brings sanity back to IT by automating network changes and decoupling applications from the network infrastructure. SDN recognizes that the purpose of networks is to support applications, and thus SDN makes applications the center of network planning and operations. This is refreshingly good!

SDN comes in many flavors, but all versions have common goals:

  • Abstraction of the network definition, to provide centralized configuration and control
  • Automation, to prevent incorrect network configurations and to respond to physical network changes and faults
  • Flexibility, to enable direct application control and exploitation of excess network capacity

The first key aspects of any successful SDN strategy are abstraction and standardization. By definition, SDN must interoperate with hardware and software from multiple vendors, and open standards are the best way to meet that objective. Fortunately, SDN standards, such as WS-man, OMI, and OpenFlow, are well-defined, field-tested, and available across a large body of products.

A second essential aspect of SDN is the controller concept, which decouples applications from network configuration details. Through the SDN controller, each application gets a simplified view of the network resources it needs. The controller handles all the network fabric changes that are necessary to deploy or relocate workloads. Controllers such as Microsoft System Center Virtual Machine Manager (VMM) integrate fabric management with VM and storage provisioning to provide centralized administration.

The third key aspect is consistency between the private and public clouds. (For Windows environments, such compatibility is enabled by Hyper-V.) This consistency gives application owners the flexibility to move workloads to whichever realm meets their security, performance, and scalability needs. This aspect goes beyond standardization to include performance-monitoring, cost-tracking, and auditing toolsets.

As you explore the power and capabilities of SDN, you’ll be better prepared to plan for the modern network in your organization. And that is very good. To learn more about SDN, visit