Software-defined networking: 'Virtualization's last mile'

Software-defined networking: 'Virtualization's last mile'

Summary: The next great frontier in IT: Uncoupling the network from network hardware.


Now that server, storage, application, and data virtualization is underway at many organizations, networks are poised as the next great frontier of abstraction. Enter software-defined networking (SDN), which will bring more benefits to organizations than simply more efficient networks.

National Gallery of Art Photo by Joe McKendrick
(Image: Joe McKendrick)

"The datacenter's resources may be dynamic, but the communications between them are still static and brittle."

That's the word from a recent report (PDF) out of Accenture, which observes that SDN takes two forms — network virtualization and network programmability.

Network virtualization, Accenture explains, "creates a network in the software realm, all the way down to virtual switches and routers. This frees applications from the need to understand the internal intricacies of the physical network". Network programmability, on the other hand, involves "centralizing control of the routers and switches in order to reconfigure them as infrastructure changes".

The market is fragmented, and no single vendor dominates emerging SDN space. The Accenture report cites high-profile examples of SDN at work. Google, for one, has adopted the OpenFlow protocol "to boost utilization on its internal network". Google anticipates that soon it "will approach 100 percent utilization of the company network" with the programmability of SDN — compared to the industry-wide average of 30 percent to 40 percent utilization of networks.

In another instance, Verizon "anticipates using SDN to relieve loads on individual datacenters to redirect traffic to other, less-utilized datacenters in different time zones". Another high-profile operation, eBay, employs SDN "to be innovative faster", the report noted. "Not only can eBay's developers create and test new network-based products and services faster, but eBay can deploy those services faster."

SDN has promise, but Accenture also has some words of caution: "SDN is complex because of all that it touches. It requires tools and frameworks that are still developing. The interim alternative of doing it yourself is time consuming and expensive. There's a difference between virtualizing your datacenter and virtualizing your entire network. But on the former scale, the benefits are too tangible to ignore."

Topics: Virtualization, Data Centers, Networking

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • I wonder...

    "creates a network in the software realm, all the way down to virtual switches and routers."

    I wonder if that's even necessary :/. If it's all abstract anyways, why try to duplicate the functionality of the physical? Why not create something entirely different?

    "This frees applications from the need to understand the internal intricacies of the physical network"

    If you're at the application level, you shouldn't be needing to worry about that anyways - you should just be sending packets to IP addresses. The TCP/IP stack of the OS should be handling the lower level worries of the physical network.

    To be honest - this kinda sounds like what TCP/IP is supposed to do.
  • Companies wanting to be like Google need to be somewhat realistic

    [full disclosure: I work at a company in the SDN space]

    A lot of people have talked about Google's OF implementation that they talked about at ONS last year. One of the things people need to realize is that there are two things required to get that kind of utilization:
    - A central point of orchestration that has a network-wide view
    - Traffic that is predictable

    The first one is what people talk about, but the second part is key too. The Google use case was a datacenter interconnect, not something they deployed on their Internet-facing links. The traffic patterns between datacenters are very predictable, due in large part to pushing lots of data back and forth. Google owns the entire stack here - both the application driving the communications and the infrastructure carrying them. This means they can more easily run hot because they control everything.

    Most enterprises don't enjoy such control. Traffic is not always predictable, nor do they have an easy way to groom traffic. This means they have to build headroom into their connections (and it's the WAN links that are expensive). This is enough to keep most enterprises from ever running at 90%+.

    Also note that this is a datacenter interconnect use case, not a pure intra-datacenter solution.

    The real challenge around SDN is identifying the right higher-level abstractions that allow orchestration to happen without a deep-seeded knowledge of network architecture. How do you describe workloads? How do define workload requirements (like latency or bandwidth)? How are workloads optimized? What triggers changes?

    The starting point for these is not OpenFlow - it's workload abstraction. Would love to see more attention on this issue. Til now, it is both unidentified and not well understood.

    Mike Bushong
    Mike Bushong
    • SDN as a resarch for Security

      Sir is it feasible topic for research(for M.phil information security) if i could merge these areas Software Development Security and Software Defined Network , some thing like security in it ...or provide some secure solutions(inherent in app) in a secure way through control plane of application interface ???
      Junaid Shah