7 Software Defined Networking Considerations

1 comment

Patrick Hubbard is Senior Technical Product Marketing Manager and Head Geek at SolarWinds.

PatrickHubbard_tnPATRICK HUBBARD
SolarWinds

The move toward software defined networks (SDN) in the data center is no longer a question of “if” or “when,” but “how.” Density and physical proximity provide a fertile environment for standardization and automation, and many vendors are proposing solutions – several even have early technologies available now. However, IT administrators should carefully consider what they’re being pitched. SDN may not be the most cost-effective solution in every case; other technology investments may pay larger or more immediate dividends.

Moreover, IT administrators should consider that vendors are not universally investing in solving all of the challenges that SDN could potentially correct – so while SDN has potential to solve all IT-related issues, the vendor solutions to do so may not be available for some time. Vendors are currently evaluating the industry landscape for the most lucrative opportunities, which will have a significant impact on the SDN solutions made available to IT administrators.

The good news is that data center networks will receive more attention and product development than other technologies (such as WANs and LANs). Network administrators should expect varying levels of functionality, compatibility, price and performance – particularly depending on how their operations are aligned with the thinking of the major vendors. Given the complexity of the SDN vendor landscape and its status as an emerging technology, there are seven main factors IT administrators should consider when determining whether SDN is right for their network:

1) The industry in which the organization is operating

Certain industries maintain higher ratios of data center investment per employee than others, and the size of the data center is the largest factor in considering SDN. Cloud providers such as Amazon, Google, Facebook and Azure rolled out their own proprietary SDN solutions years ago, and likely could not operate today without them. For these large providers, vendor-agnostic standardization is the goal, and their next target is the top-of-rack switch. An organization that maintains dozens of racks or more should pay attention to what these big cloud players are doing. What we’re seeing from vendors: We can expect upstart vendors to produce commercial versions of open reference architectures, and hopefully, more standardization from established vendors as SDN matures. The potential exists for significant savings as SDN allows data centers to move away from single source hardware to the commodity-based pricing we see with servers.

2) The size of an organization’s network

A data center with near or above 1,000 active IP addresses is also a candidate for SDN. This is especially true if the majority of those addresses are assigned to virtual machines. What we’re seeing from vendors: In this arena, we can expect hypervisor/virtual machine (VM) vendors to rush to be the SDN controller, and push hardware vendors to expose rich Southbound SDN APIs. Controllers will be a new line item in the IT budget, and it’s expected that VM vendors would want to control the vSwitch, rack, and core as a single unit with their software.

3) The dynamic nature of an organization’s applications and workloads

An organization with fairly stable IT operations where systems agility is not a competitive differentiator might hold off on investing in SDN. While it may be cool to configure traffic with a mouse, the existing, skilled team with PuTTY (a telenet client) may remain more cost-effective for some time.

4) The number of virtual machines (VMs) within an organization’s network

Besides the number of IPs assigned to VMs in your primary data center, the total number of VMs across an organization’s network is also a consideration for whether to implement SDN. Imagine an SDN controller with both Northbound and Southbound authority managing a data service VM. Based on network traffic analysis, it might determine that the VM would be more efficient located in a remote data center closer to its clients. The controller would send a command to vMotion the server, while coordinating network changes across the enterprise to reconfigure for the new location.

5) The organization’s need for agility, flexibility and scalability within the network

Especially relevant for hybrid cloud/local data center customers, SDN may provide greatly improved flexibility by removing the traditional demarcation points between networks. Remote, local and virtual networks are normalized into a common entity, differentiated by properties rather than physical interfaces. What we’re seeing from vendors: Watch for cloud providers to continue extending their hybrid management tools in this area. Microsoft in particular has focused on hybrid support, though only on its platforms.

6) The organization’s need to simplify security measures and control access to applications

The application of best practices, policy-based management and routine auditing as it relates to network security and access are a challenge within traditional networks. With SDN, the network itself can define and attach policy to any context: an application, user, flow, endpoint or device. If an organization has complex or critical security requirements, SDN intelligence services will be critical. What we’re seeing from vendors: Expect existing network management and security vendors to expand their products’ abilities to analyze the virtual networks under an SDN controller’s authority.

7) The organization’s access to personnel and capital resources

As is always the case with IT, only SDN projects with clear ROI will be approved. An IT organization with a limited budget or only a handful of specialists may not be a viable candidate for SDN. As with server virtualization, IT shops of every size will eventually benefit from SDN, but it won’t happen overnight. What we’re seeing from vendors: Even with the server virtualization market mature for some time, Microsoft only recently put viable “free” VM hosting in the hands of SMBs with Hyper-V, and likewise, there’s no vendor rush where SDN budgets are small.

Keep Grains of Salt Handy

Finally, IT administrators should consider whether vendors are promoting solutions in the spirit of Stanford’s original research in 2005, which served as the genesis of SDN and sought to solve common networking challenges. The dream of SDN – separating the networking software layer from the hardware layer – is the dream of network administrators: automation based on rules to reduce or even eliminate manual workloads and result in fewer configuration errors and less downtime.

However, vendors protecting install bases may discourage solutions that release IT administrators from single-vendor infrastructures. For IT administrators that aren’t implementing SDN in the near term, there are plenty of great solutions to ease the pain of network management. A variety of freeware and commercial applications are available today that can monitor and manage network configuration, performance, access and security. Expect current products with multi-vendor support to extend monitoring and management into SDN as the technology matures, supporting SDN and non-SDN assets in a single solution.

Industry Perspectives is a content channel at Data Center Knowledge highlighting thought leadership in the data center arena. See our guidelines and submission process for information on participating. View previously published Industry Perspectives in our Knowledge Library.

Add Your Comments

  • (will not be published)

One Comment

  1. This is a pretty good list and very practical. I was a little surprised to see more treatment of capex than opex. SDN might reduce capex some, but the white box switch movement alluded to in the first item is really more about building the same networks we have today... but with cheaper boxes. The real drive behind SDN is workflow automation. There are things you can do from a controller that you cannot do (or at least not as easily) in a heavily distributed environment with no global view of resources. This automation is going to impact opex not capex. And so you would think that things like rate of change, size of operations staff, and density of operator-introduced network issues might be indicators of who is well suited for SDN. You kind of allude to it so I will underscore here, but the other thing that is on the rise is a more application-focused network environment. The infamous "northbound API" talked about in SDN circles is about creating a standard communication vehicle that will be useful here. And recent work in workload abstractions should benefit this effort as well. Mike Bushong (@mbushong) Plexxi