Making the Business Case for SDN
By now, it's almost a given that software defined networking will usher in a revolution in the design and development of data infrastructure. Environments will become leaner and cheaper both to implement and to operate, and enterprise infrastructures themselves will improve the productivity of both data users and the data itself.
And yet, as we embark upon the initial SDN deployment phase, it seems the enterprise may once again be falling for the promise of a new technology with little understanding of its true value. As with PCs, servers, and storage networking, the consensus seems to be "Deploy first, make the business case later." But what is the business case for SDN?
Based on current knowledge, it looks like the operational benefits of virtualized networking will outstrip even those of virtualized servers and storage. The advantages of dynamically provisioning and then reconfiguring end-to-end network architectures completely in software cannot be overstated. They will clearly produce not only a more streamlined network infrastructure, but a more rapid application provisioning process, as well as improvements in the management of numerous critical network functions, such as security and load balancing.
The Last (and Necessary) Link in the Virtual Chain
In fact, with server and storage infrastructure already highly virtualized, many organizations are turning toward SDN not because they want to, but because they have to.
"Historically, it took months to provision a server, so the fact that it took two weeks to get the network up and running was hidden," said Joe Skorupa, vice president and distinguished analyst at Gartner. "That is no longer acceptable."
Making it even more unacceptable is the fact that many organizations are looking to push infrastructure to hyperscale levels in anticipation of Big Data, mobile traffic and advanced sync/sharing services. With physical networks simply incapable of handling such a dynamic load, enterprises will find that SDN is necessary, regardless of the long-term ROI.
"In simple datacenters with a limited number of tenants/objects, an existing VLAN approach is relatively manageable," said Juniper marketing director Steve Shaw. "But as the number of tenants expands – and Juniper is working with one SaaS company with approximately 40,000 virtualized workloads – the management, provisioning and maintenance of connections between VMs becomes literally impossible without a virtual network overlay system. Throw in workload mobility and federation of disparate data centers, and it becomes clear that a new approach is required."
Cost Savings: A Basic Calculation
On one level, calculating the economic benefit of software defined networking should be quite easy. Start with the cost of the networking hardware it will make redundant, add the reduction in labor costs for network management, application provisioning and other relevant ancillary functions, and subtract the total from the cost of SDN implementation, operation, and management. Then compare that number to the acquisition and operational costs of your current setup or your other future options. Even small organizations stand to benefit greatly from this equation, whether they continue to build and support internal infrastructure or place their faith in newly software-defined infrastructure in the cloud.
So far, the numbers look promising. Some estimates suggest that enterprises could see up to a 95 percent reduction in capital costs by implementing commodity silicon within switching infrastructure. Similar reductions are feasible on the operations side due to savings in real estate, power, cooling, cabling and a host of other factors that come from streamlining today's multi-tier architectures into flatter, fabric-based infrastructure. Over the long term, however, viewing SDN options through a simple cost savings lens may not be the best perspective.
More than Just Networking
SDN's benefits, after all, aren't limited to actual networking. Even at this early stage, it is clear that software defined networking promises a whole lot more. The very idea of a fully virtual data infrastructure introduces unprecedented levels of agility up and down the entire business model, from product development to sales and marketing and, ultimately, customer fulfillment.
"This goes far beyond networking, absolutely," said Mat Mathews, co-founder and vice president of product development at networking developer Plexxi. "It entails things like the user experience and improved response times for applications. Ultimately, it is the overall performance improvement of data operations that will prove SDN's value, and that is very difficult to quantify."
On the operational side, a key facet is the speed at which new application development environments can be implemented. The leading platforms convert what is currently a weeks-long process to literally a few minutes, which means new products and services can be brought to market faster, possibly leading to multi-million dollar revenue streams pouring in at an accelerated rate.
"You can look at cost avoidance, but you still haven't captured [SDN's] true value," said Gartner's Skorupa. "What is the value of agility? What is the value of responsiveness? The CIO could say that if the enterprise doesn't do this, then internal customers will go to an external host, but what does that mean to the business?"
A key variable on the operations side is how dependent the enterprise is on home-grown app development. Organizations with the ability to build, test and deploy their own apps will benefit enormously from the lightning-fast provisioning and broad scalability that SDN engenders. Those that plan to simply layer prepackaged services on top of the controller will largely miss that opportunity, but will still see incredible agility when it comes to pushing those apps out to users by not having to manually reprogram the entire network to accommodate each change.
Still, with all the SDN platforms and configuration options available to the enterprise (see page 2), is there any way to gauge which solution provides the best functionality at the lowest cost? Ultimately, it depends on what kind of functionality you hope to achieve.
"It comes down to what is most important to the enterprise," said Rod Stuhlmuller, director of product marketing at VMware's Network and Security unit. "All customers want speed and agility, but some are trying to operationalize everything by reducing capex as much as possible. Others want just the opposite by placing everything on capex and then line-itemizing costs on the opex side."
In that vein, enterprise executives will have to do some hard number crunching when it comes to the best way to deploy SDN. Legacy infrastructure will likely play a large role for many, but it is unclear whether today's network infrastructure will have the chops to deliver on the promises of a fully federated, dynamic network environment. Consequently, there are numerous options on the hardware implementation side, from fully open, multi-vendor platforms to proprietary implementations, all hitting different price points.
The Long and the Short of TCO: Beyond Price-Per-Port
In each of these scenarios, however, experts advise against employing the standard price-per-port analysis when calculating TCO. When we're talking about improving data agility and flexibility over the long run, skimping on initial deployment costs could come back to haunt you.
"If you build a new network architecture at the lowest price possible, you satisfy a Year 1 issue, but there are still Year 2 and Year 5 issues to deal with," said Plexxi's Mathews. "The paradox is that everyone complains about the opex cost of networks, but their first question is usually the cost per port. SDN deployments should focus more on the totality of network costs, not just the cost per port but downstream, when things become more costly and painful."
There is also the fact that SDN will be of limited use without a solid automation layer, one capable of analyzing network patterns and traffic loads in real time and effecting changes seamlessly without hampering resources elsewhere. In fact, SDN offers a unique opportunity to integrate today's multiple, function-specific automation stacks into a federated automation layer.
"It's a question of how do we get the benefits of software programmability," said Cisco Distinguished Engineer Jon Woolwine, who has been tasked with implementing SDN on Cisco's internal infrastructure. "We are starting to see that with a common platform like the controller, there are other opportunities for automation."
As examples, he noted that functions like remote access, security, QoS management and others can be coordinated on a policy level, with the controller handling all of the details needed to implement those policies across multi-device, multi-platform infrastructure. Ultimately, this is what enables the rapid deployment of new services and applications, since IT personnel no longer have to physically adjust hundreds or even thousands of devices in order to support the new working environment.
In the end, the business value of SDN, and hence the deployment model and upper-level architectures that enterprise executives choose to employ, will come down to two primary factors. Are your current network costs rooted in capital or operational expenditures? And what kind of network functionality do you hope to gain by converting to a software-based architecture?
At this point, the earliest adopters are just starting to grapple with these issues. It could be a year or more before hard data on costs and deployment options turns up. But ultimately, it's hard to imagine a scenario in which SDN does not produce dramatic cost and capability advantages over today's static silos. As VMware's Stuhlmuller puts it:
"Clearly we reduce application deployment from weeks to minutes. Clearly we can extend these capabilities to existing infrastructure. Clearly we can provide a lower-cost physical infrastructure. All of these things may affect individual enterprises differently, but they will all achieve a better TCO."
Page 2: Overlay, White Box or Custom Hardware: The Three Routes to SDN
Overlay, White Box or Custom Hardware: The Three Routes to SDN
In the software-defined world, network architectures will be about as diverse as today's physical infrastructure. Every enterprise will have a unique set of requirements that calls for custom solutions. The difference is that these idiosyncrasies will be much easier to implement in software than in hardware.
For the moment, there are three distinct deployment models on which these software architectures will be built: overlay technologies on existing infrastructure, vendor-specific solutions using customized ASICs, and white box deployment on commodity hardware.
Selecting one of these options will require a thorough evaluation of current network capabilities and future goals, and it isn't entirely clear whether any of them will provide optimal service, given that all we have to go on at this point is vendor claims.
VMware, for instance, views SDN from an all-software perspective, which means it can inhabit a wide range of hardware configurations and allow policies and services to extend all the way to the hypervisor, which the company says provides a high degree of operational flexibility.
"We call it 'microsegmentation,'" said Rod Stuhlmuller, director of product marketing at VMware's Network and Security unit. "We can segment [network control] all the way down to the virtual interface on the app, which allows us to make changes centrally and push them out to whatever virtual instances they are associated with."
Naturally, a company like Cisco says there are holes in this approach.
"There are much greater opportunities once you have hardware and software working together," said Cisco Distinguished Engineer Jon Woolwine. "Eventually, I'm going to want to have control of the network infrastructure that supports SDN, and to do that you'll need visibility and the ability to troubleshoot. If you are blind to that piece of the infrastructure and you are unable to control it, not only won't you be able to overcome things like hardware dependencies, but there might be opportunities for efficiency and optimization you might miss."
The question, though, is whether you need a customized ASIC found in hardware like that offered by Cisco and Juniper. If you don't, you might instead adopt the lower-cost solution of white box hardware for simple packet forwarding so that performance issues can be addressed through automated load balancing and other functions. In the latter case, expect to see a high degree of standardization emerge across a range of hardware and software systems. This standardization will be needed not only to simplify the deployment process, but also to ensure that network changes can be implemented immediately across the now highly integrated infrastructure.
In all likelihood, it's a debate that won't be settled until the enterprise gets some real SDN experience under its belt.