07 Aug SDN: The ‘S’ Doesn’t Necessarily Mean “Someday”
Software Defined Networking (SDN) is currently one of the hottest buzzwords in the enterprise market. SDN promises to take much of the complexity and operational cost out of stringing together the thousands of servers and applications that power today’s modern data centers. For x86 servers, the move to virtualization, with more than half of the new servers being deployed virtually, meant that the application/OS layer was abstracted from the hardware below. This abstraction allows a more fluid and responsive computing environment and is the enabling foundation for cloud computing. However, while the servers became more flexible and programmable with businesses becoming more agile, the network has lagged; the routers and switches that drive the network have not progressed at the same rate.
Traditional routers have a control plane and a data plane. The data plane is self-explanatory; it represents the billions of packets being pushed through the pipes, and the control plane helps direct those packets as well as provide other administrative functions like enforcing policies and segmenting networks. SDN hopes to achieve better efficiency, responsiveness and elasticity by separating the control plane from the data plane. Traditionally both planes were in the same router, but with SDN, the control moves out of the router and is centralized.
Most of the routing control comes from the core routers which are augmented by end of row and top of rack switching below, creating a hierarchy for data to flow both northbound and southbound.
Programming these routers is as much an art as a science – the interactions of different applications, combined with rules and prioritization – creates a significant degree of complexity.
Physically, every time one needs to deploy a server, move a server, add more bandwidth or switch resources, they are touching the rack – a task that is fraught with risks of unintended consequences if the wrong cable is pulled or the proper governance models (which dictate the rules and processes around deployment, configuration, security, access, etc.) are not followed.
SDN promises to automate much of this and move from physical connections ruling the data communications to smart applications handling the work, by moving some of the routing intelligence down to the server level and removing much of the intelligence for the corresponding layers of switches and routers. Through this strategy (and flattened hierarchy), less intelligent routers and switches can be deployed, implying a significant cost savings for the typical data center. But is that reality?
SDN faces several challenges and barriers to acceptance, chief amongst them are standards, strategies, cost, disruption (with corresponding pace of change) and vendor lock-in.
Let’s dive a bit deeper and look at how these different factors are impacting the move of SDN from theory to production.
Standards pose a particularly thorny problem for SDN. Through standards technology becomes pervasive, but while standards make it easier for customers, they present a problem for vendors who want differentiation. When your widget has the same standards as your competitor’s widget, customers can easily move between vendors’ products. This substitution factor drives down margins and profits; just look at the margins of the client PC business. Many years ago this business was tied to proprietary chipsets, components and designs, but over time they evolved into reference designs built mainly on commodity components and contained a common set of features, which drove down both costs for the manufacture as well as margins. Now compare that to margins in the tablet market which is built around fewer standards for now and enjoys a 200-400% advantage in margin.
OpenFlow is the de facto standard for SDN, but networking vendors generally want to add their own “secret sauce” on top. After all, the “software” part of SDN makes it easy to layer something on top, potentially without customers even understanding what is and is not proprietary. This can make managing equipment from multiple vendors more difficult. From that aspect, if SDN is supposed to increase efficiency, but instead of managing routing policies you’re now managing platform differences, are you any better off?
Today vendors are creating OpenFlow-aware products assuming that the market is headed in that direction. OpenFlow will be integrated into almost all enterprise networking products, but if the market can’t agree on more standards around the controller, it risks becoming like Firewire (IEEE 1394), ubiquitous on devices, but rarely used outside of a handful of niche markets, leading to it eventually being surpassed by its competitor, USB.
Every company seems to have an SDN strategy these days, and these companies tend to fall into two categories, what we’ll call the “haves” and the “have nots.”
The “haves” are established networking companies like Cisco, Juniper, Oracle, Emulex and VMware to name a few. These companies have existing products in the market (and have for years). While they have an SDN strategy, make no mistake, they aren’t making money off of SDN today and would be quite comfortable if things didn’t change, because they are the incumbents with a profitable existing business and products to protect.
The “have nots” are newer companies not held down by their legacy product lines. Companies like Plexxi, Embrane and Big Switch Networks are examples of companies attacking from the other direction, entering the market with an idea, but not baggage.
To compete, the established players generally have an acquisition strategy because there is not time in most cases for organic growth in this area. While this may spell good news for customers as promising technology gets the capital to back it and a sales force with existing customer footprint, there is another side to things. Take Oracle’s acquisition of Xsigo, where the technology went from a horizontally applicable appliance to a thin slice of an Oracle vertical stack, leaving non-Oracle customers out in the cold, not to mention the channel partners, developers and technology suppliers for the platforms. VMware did a much better job integrating Nicira into their ecosystem, there is a far greater probability of successfully integrating this into a long-term SDN strategy. A still relevant discussion of this can be found in this article.
Another good comparison between two players is the approach that Cisco is taking with the Open Network Environment vs. Juniper. Cisco is stressing the idea of “open” but in reality, the open piece extends mainly to Cisco, its partners and its 3rd party developers (who are developing applications and tools specifically for Cisco environments.) Juniper, while an established player with significant share to defend, is focused more on the customer and the processes that are required to move from today’s environments to SDN. Their methodology begins with identifying the four planes (management, services, control and forwarding) which essentially carves up the functions of the control plane into subsections. With those identified, customers can begin the trip towards SDN with centralization, offloading to the cloud and standardization being some of the key steps that they recommend. When you contrast how these vendors’ approaches differ it is clear that one is interested in defending their share and the other is interested in helping the customers build out a longer-term strategy.
The traditional server OEMs (Dell, HP, IBM etc.) are also engaged in networking, mainly focused on edge devices (top of rack), less so at the core. These OEMS have a unique opportunity in front of them to leverage the SDN disruption on edge devices as the intelligence moves away from the top of rack and end of row switches towards server-based SDN appliances and applications. SDN threatens to move today’s multi-tier routing complex of core, EOR and TOR to core and SDN appliance, which can run on x86 servers. However the OEMs’ strategies are less cogent and not as focused on the integration of networking and servers. The concepts behind SDN focus on removing the barriers, flattening the stack and shifting the paradigms/traditions for network routing. If OEMs hope to capitalize on this they need to pick up the SDN playbook and address controllers from a more holistic standpoint, not just through their networking products team. They will need to have a multi-controller strategy as the “not invented here” syndrome will hold back success. Enterprise management tools are a great example – people use the OEM tools today but only for very basic device-specific tasks, they don’t rely on them to manage their entire network. We’ll have to see if their strategies progress over time to be more inclusive.
Obviously the goal for any SDN deployment is going to have a promise of lower operating costs over time. The cost savings comes in two primary places – lower hardware cost and lower operational costs, the bulk of the savings coming from the latter. The implied lower hardware costs represent an opportunity for other edge players to shift customers away from Cisco, the networking leader because customers are predisposed to saving money. (If you don’t care what you spend on networking, you’ll continue down the status quo path.) But at the same time that the door at the top is opened to other vendors, there is also a challenge from low-end devices from China that are becoming popular with hyperscale data centers that are already deploying OpenFlow. Just as these hyperscale customers have reached out to Taiwan to build their own servers, these players are also taking a non-traditional approach to networking with SDN and if this takes hold, there could be a new set of players in the market.
From an operational standpoint, SDN can reduce costs by reducing touch time (or touches altogether) when provisioning or reprovisioning servers as well as reduce the day-to-day management costs, making administrators more efficient. But those savings can only happen if customers standardize on their SDN components. There’s the rub: you can drive down costs by standardizing on a single vendor, but standardizing on a single vendor generally brings less leverage with that vendor, resulting in higher prices. Most companies today have a standard server across their data center, but second source another server to help maintain competition amongst the vendors, keeping prices down. But with SDN, implementing two different SDN controller strategies in order to keep hardware costs down results in a potential Catch-22 of higher operational costs. While both may be based on the same OpenFlow protocol, the management of two different controllers and having to comprehend each controller whenever addressing the routing means higher operational costs down the road.
A real concern for SDN is how to measure the actual savings. For power efficiency, many customers were not concerned with power efficiency because facilities paid the bill. The first time that a CIO was told “no more servers, you’re out of power”, power efficiency became a real issue (much like a $5/gallon gas in the US would drive tremendous demand to the hybrid car market. Hyperscale data centers, who measure PUE for power efficiency are also interested in data transfer efficiency, so SDN is a natural for them. SDN has a dramatic CAPEX hit as companies begin replacing networking equipment and spending money on expensive software, but the OPEX savings happens down the road. Much further down the road, so how does a CIO decide to take the plunge when the ROI is so cloudy – spend hard costs today for a potential soft cost savings down the road?
The migration to SDN is a major concern both for customers and vendors because it disrupts a customers’ existing environment and processes while simultaneously disrupting a vendors’ product line and strategy. For greenfield projects and brand new data centers, there is an opportunity to deploy SDN, but this opportunity, outside of a handful of hyperscale companies, is clearly at odds with today’s market dynamics. Vendors and customers alike will venture into SDN carefully as they try to serve both sides.
For the majority, the question will be how to implement in an existing network environment, where technologies change slowly and refresh cycles don’t cleanly match those on the server side? For instance, 10Gb Ethernet began shipping around 2008, and most expect it to finally overtake 1Gb Ethernet in servers some time in 2014 but in that same time period we have seen 3-4 generations of server CPUs and a quadrupling of capability. Companies like Dell, for instance, have developed a strategy that focuses on decentralized SDN today, moving to centralized over time. They recognize that this migration will take time, but there are steps that can be taken today that leave the baby in the bathwater.
Those that are expecting a groundswell of SDN projects to materialize need to face the reality that this will not be a fast transition like server virtualization. When VMware hit its prime and everyone was talking about virtualization, the silicon infrastructure was already in place (and rapidly improving with each generation.) Customers could deploy a virtualization-ready server with a standalone OS and later flip the bit, easily moving to virtualization, because it was a single entity to contend with. In an SDN world there are too many moving parts to easily flip that bit. With a larger number of moving pieces, almost every piece will need to be aligned before a transition can begin.
While servers are relatively inexpensive and generationally change every 18 months, networking equipment, especially core routers, have lifecycles approaching 5-7 years for many customers. Cisco estimates that most of the upper level core switches in the market today have not been fully amortized so until those multi-million dollar pieces of equipment have been paid off, don’t expect them to be pulled from operation. All of this points to the potential for longer delays in SDN acceptance outside of hyperscale and new deployments.
SDN Vendor Lock-in
As mentioned before, the established vendors have a built-in incentive to slow the pace of change, based on existing products and existing customers. A challenge to the status quo represents business risk for these vendors. Why would large, established players like Cisco and Juniper, who have existing share to defend, want to introduce a technology that promises to marginalize the top of rack edge networking? The smaller vendors are generally offering point tools, not end-to-end solutions and the danger in buying into their vision is that they may become cash-flow starved, or, worse, bought out by one of the larger vendors. As a customer is it worth the risk? What if the company that you place your bet on is acquired by a larger company that you don’t care to do business with?
The very promise of SDN mimics the promise of virtualization: free yourself from the manual hands-on processes, simplify your environment, and turn networking into an elastic resource that can be easily deployed, moved and adjusted – in real time – to suit the needs of the business. But, just as companies discovered with virtualization, solutions from one vendor are not easily interchanged with another. Many customers have found that they can maintain islands of virtualization with VMware for their critical applications and another hypervisor for their less critical servers, but this is far harder to manage in a networking environment that by default is designed to connect the islands.
The vision of an autonomous network with real-time analysis and adaptive routing simply cannot be achieved without a complete network stack from a single vendor. Much the same way that Apple can keep consumers in a simple and easy to use ecosystem, as long as everything has an Apple logo on it, that pipe dream of a truly adaptive network requires a single brand.
The enterprise market has moved from the larger proprietary mainframes to mini computers and finally Industry-standard servers that brought standardized, modular designs, making them ubiquitous. Once we had settled on the “standard” the next big breakout was hyperscale data center platforms which took a variety of form factors, but as an aggregate energized the market. Today we see complete stacks like big data clusters for Hadoop and Oracle’s Exadata as examples of where the market is going. Building blocks aren’t sexy, and neither are top of rack switches. For someone to do it better, they need to challenge the existing groupthink.
The next beachhead for networking vendors to lock in customers is expanding, from the management tools of today to SDN in the future.
SDN Vendor Snapshot
|Positioning||Cisco Open Network Environment (ONE); “a comprehensive solution to help networks become more open, programmable, and application-aware.”|
|Opportunity||Defend existing share, comfort customers with vision, reinforce “safety” of the Cisco ecosystem|
|Risk||SDN takes off, Ethernet routing is marginalized and customers stop paying a premium for TOR/EOR devices, driving down margins|
|Prognosis||Cisco’s 60%+ share of the L2/L3 market is greatly at risk as SDN marginalizes routing devices in favor of software-based solutions|
|Positioning||“SDN delivered through HP will enable your organization to experience applications as never before, since the network is automatically tuned through SDN.”|
|Opportunity||Attack SDN with a multi-controller strategy that merges the pervasiveness of HP ProLiant servers with SDN and layers on professional services to make it all work|
|Risk||With >8% of the market HP has been able to move above the lower single digit share crowd but they need a better vision than an “all HP” world because they don’t have the footprint today to make that work|
|Prognosis||HP stands to potentially gain if they can figure out how to leverage ProLiant and open their ecosystem|
|Positioning||Provide a coordinated virtual infrastructure enabling applications and the network to collaborate for a high quality user experience and optimized resource consumption|
|Opportunity||Focus on metrics-driven CIOs and exploit the AL Pod and Mesh technologies|
|Risk||Building on their own protocols instead of OpenFLow|
|Prognosis||Can probably retain install base but will have difficult time taking share|
|Positioning||Enable companies to accelerate the design and delivery of new services, lower the cost of network operation, and provide a clear path to implementation.|
|Opportunity||Focus on the customer and the deployment, take the SDN high road|
|Risk||Focus on software and processes over hardware|
|Prognosis||Needs to find a way to monetize the processes and methodology|
|Positioning||Virtual Network Architecture and Open Automation Framework gives customers a way to ease into SDN|
|Opportunity||Attack “brownfield” opportunities with methodology; attack hyperscale with DCS|
|Risk||Low network market share makes thought leadership difficult|
|Prognosis||Potential to capture some business but needs to capitalize on smaller opportunities quickly to establish credibility|
|Opportunity||SDN provides the disruption to allow other players to stake their claim in the market by delivering the capabilities early, especially to hyperscale customers|
|Risk||With SDN already seen as a risk, these vendors need to instill comfort in customers, not play the disruptor|
|Prognosis||With 20% of the market buying from the “other” category, there is an opportunity for disruption from this set of vendors if one can embrace SDN and become the de facto leader|
What Does This Mean For The SDN Market?
Clearly, SDN will continue to be the hot buzzword, think of it as the “Cloud Computing” of the network space. That hype cycle will continue to capture eyeballs and drive vendors’ pitches, but in terms of actually seeing an appreciable difference in the amount of SDN in production environments, the acceptance curve will be far flatter than virtualization. Here is our view of the market:
- From a supply side perspective, expect the incumbents, the larger, established networking vendors to focus on acquisitions in order to fill out their portfolios. Cisco has never been afraid to crack open their checkbook in order to grow top line business or invest in strategic directions, so they will be a primary candidate to keep tabs on as SDN continues to gain steam. But as these companies engage in acquisitions, remember that this is often force-fitting products or technology more often than a methodical process to align like technologies. Nothing keeps the disruptors from altering the market dynamics like being consumed.
- Also on the supply side, the traditional OEM players on the server side have an opportunity to gain share at the top of the rack, but only if they can leverage their server share and open their support of SDN controllers. OEMs can play the disruptor card, but they can’t do it from an incumbent position. HP clearly is challenged here as it has a decent share of the TOR market, but in order to take advantage of SDN it needs to step outside of its own walls and see what is truly driving the market. It is fine to have your own controller, but delivering a path to multi-controller support not only increases the addressable market, but also increases the probability of selling enterprise services which add handsomely to the bottom line.
- On the demand side, hyperscale data centers will move more quickly to deploy SDN as they have the benefit of building out new greenfield data centers versus trying to retrofit existing deployments. Unlike traditional businesses where spending and costs can be stove piped across organizations, for hyperscale customers spending a little more up front in CAPEX to reduce OPEX is always a safe bet because that keeps costs from scaling up as the business is growing quickly. Their proven track record on flouting the existing standards from both a platform and a supply chain perspective are good indications that they can leverage change and make it work for them.
- Rounding out the demand side will be the traditional data centers will more conservatively towards SDN, waiting until the last possible moment to jump in the pool. There will be some greenfield opportunities but most of their opportunity will sit in “brownfields”, existing data centers, and they will not make changes here unless absolutely necessary. Eventually they will embrace SDN down the road, and when they do it will be similar to server virtualization but with a significantly longer honeymoon. First in the labs, then in limited pilots, and finally in wide scale production. The goad for these customers will be reduction in headcount and reduction in the manual (error-prone) configuration and reconfiguration. With the OPEX savings less clearly understood for these customers, the transition can’t be rapid.
With the tools not mature enough for most customers at this point and an emerging ecosystem without all of the key pieces in place, not actively piloting SDN today is not putting your business at a disadvantage. However, with the rate of change expected in the very near future, every organization needs to be assessing SDN to understand a.) if SDN is solving their current/anticipated future issues, b.) how SDN can fit into their current environment and c.) if the vendors that they are aligned with today will be the same vendors that they will rely on for SDN.
Don’t assume that because you are standardized on a particular vendors’ equipment today that this vendor will be the best partner in the future. SDN brings us to a crossroads and the current trajectory might be begging for a change.
John Fruehe is a guest blogger at Moor Insights & Strategy and was previously vice president at NextIO and director at AMD. John also spent nearly 15 years at Dell and Compaq in enterprise product, strategy, and marketing roles. You can find his full biography here.