SDN architectures

The Three Faces of SDN

As software-defined networking (SDN) becomes more popular, vendors wrestle to promote visions of the technology that put their own products in the best light. That's natural for the lifecycle of any emerging technology -- every vendor needs to be able to say, "We do that."

I separate the vendors into three different buckets. This is not rigorous at all, just a handy mental guide to help think about SDN. The three buckets are the Pure Players, the loosey-goosey school, and the zombie army of the White Walkers. (For a more rigorous definition of SDN, see Defining SDN & NFV.)

Pure players
The pure vision of SDN is built on dumb commodity switches, with all the intelligence running in central controllers, as described by OpenFlow and the Open Networking Foundation. The vendors in this bucket either sell commodity switches, like Big Switch Networks and Pica8 Inc. , or they sell software, as in the case of Cumulus Networks. (See Murray Leads Big Switch Into Bare Metal Battle, Pica8 Adds Muscle to ABC – 'Anybody But Cisco', and Cumulus Intros Network OS.)

The goal for the vendors in this bucket is to make the network more flexible. Carrier networks lag far behind data centers in flexibility and virtualization. Data centers began switching from proprietary to commodity hardware in the 90s, and that technology became standard in the 2000s. Networks are just now beginning that transition. The result is that you have incredibly sophisticated virtual data centers that can be configured on the fly entirely in software. When you configure the network underlying those virtual servers, that requires hardware changes. You need to send out a guy wearing a Game of Thrones T-shirt to move around hardware and plug things in manually.

Changes take weeks. This contributes to a perception that carriers are hard to work with and slow. That's not a good way for a business to be perceived.

The pure vision of SDN puts all those changes in software, which saves on opex. And the hardware is inexpensive and interchangeable, so carriers and enterprises save a lot of money on capex.

More importantly, carriers suddenly become as flexible as cloud providers. They can provision networks in minutes or hours. Combine SDN with NFV, and suddenly carriers can replace CPE with software, and do neat business things like offer 30-day trials of new services. Indeed, SDN (and its cousin NFV) are vital tools to help carriers make the transition to cloud providers. (See Why Verizon Needed a Cloud Reboot, NTT Taps SDN to Enhance Cloud Flexibility, and A Peek Inside CenturyLink's Cloud Expansion.)

The problem is that this kind of transition is a huge task. Data centers took decades to make the transition to open systems. Linux Torvalds released the first version of Linux in 1991. The technology required 20 years to mature, until finally Sun Microsystems, the queen of dotcom servers, fell to competitive pressure and was acquired by Oracle in 2010.

Will the transition to SDN be faster now that open systems in the data center have paved the way? Perhaps, but we're still talking about the better part of a decade at least. Service providers, particularly Tier 1s, have billions of dollars of sunk costs in traditional networking. Only a fool would burn all that down to make a greenfield start. The transition will be gradual and cautious.

However, even in the short term, we'll start seeing niches where SDN is valuable. SDN provides competitive pressure on traditional switch vendors like Cisco Systems Inc. (Nasdaq: CSCO), Juniper Networks Inc. (NYSE: JNPR), and Brocade Communications Systems Inc. (Nasdaq: BRCD).

Next page: The loosey-goosey school

1 of 2
Next Page
Page 1 / 2   >   >>
Mitch Wagner 5/10/2014 | 3:39:00 PM
Re: Seems relevant Oh, I think I see. Companies will save on opex through SDN, but the flexibility will create more demand for services and more demand on the network, leading to greater opex overall. Is that it?
Mitch Wagner 5/10/2014 | 3:36:05 PM
Re: Tightening up the loosey-goosey face of SDN... How can a company use a DIY approach to a public cloud? The essence of public cloud is to let an outside company (Microsoft, Amazon, etc.) run the cloud service for you. That's the very opposite of the defition of DIY. 

Likewise, you can't have a hybrid model on an all-private cloud. A hybrid cloud is part-public, part-private, whilea  private cloud is all-private. 

What am I missing?
sam masud 5/9/2014 | 1:39:59 PM
Re: Seems relevant Mitch,

Sorry if my post came across as an oxymoron (or maybe just moronic), but what I meant is that overall opex will increase because SDN will make it easier to tailor more services/apps to more subs. I could be wrong, but that would not be the first time :-)

Houman0 5/8/2014 | 7:19:13 PM
Re: Tightening up the loosey-goosey face of SDN... Thanks Mitch!

In fact either private or public clouds can be built using a Do-It-Yourself (DIY) or shrink-wrapped model. Just that the priorities & needs they optimize for are different. Leading enterprises for whom IT is a critical asset (like financials, healthcare, and many manufacturing concerns) often lean toward picking best of breed sub-components and want the flexibility to mix and match to maximize performance, control/auditing & economics for their most essential apps. 

The hybrid cloud certainly emerges in popularity (initially more in theory than practice) as companies want to burst flexibly outside and above the bounds of their private clouds. But again, hybrid "environments" are more a more practical & important consideration today.

And hybrid environments exist everywhere, even in private clouds.  A hybrid environment, for instance, is one in which an enterprise wants to use different hypervisors (say KVM in some racks or datacenters, and ESXi or XEN in others), or has an established VMWare environment in place but also has several OpenStack projects underway in parallel. All of that could (and is) easily be happening in their private cloud.

Using a properly designed overlay virtualization approach, with a policy framework that is agnostic to the network infrastructure, that can be accomplished today and that's pretty cool.

It's definitely a gold star for some of us in the loosey-goosey camp :)
Mitch Wagner 5/8/2014 | 4:32:32 PM
Re: Tightening up the loosey-goosey face of SDN... Hi, houman - Absolutely, Nuage is doing fine work and they belong on the list. 

I suspect that what you are calling "DIY" and "shrink-wrapped" are what many people call "private" and "public." And there's a  third model too, gaining popularity: Hybrid. 
Mitch Wagner 5/8/2014 | 4:25:56 PM
Re: Seems relevant sam masud - Sorry, I don't understand your question? Isn't "lower opex" the same as "comparatively lower"?
Houman0 5/8/2014 | 4:22:08 PM
Tightening up the loosey-goosey face of SDN... Hi Mitch,

There's more to the "loosey-goosey" face than meets the eye, and let's not forget Nuage Networks in that camp. (see http://ubm.io/1jlBxQG ). Especially to the extent that the flexibility of well-implemented overlays is combined with appropriate underlay awareness, and a common policy framework can be applied across all assets (virtualized or bare metal), in hybrid environments, across different hypervisors, agnostic to the network equipment, then you've actually got something pretty tight & useful... For Westeros & White Walkers alike, by the way...

As for whether overlays are doomed in the long run, lets check back in the long run. Other overlay approaches took a while to get right (VPNs), but have withstood the test of time pretty nicely.  

Underlays & overlays aside, and perhaps more fundamentally, there are 2 basic models for the cloud: The "DIY" model & the "shrink-wrapped" model. They each have merit and will co-exist, serving different needs with different economics & different tradeoffs. Some of the world's largest enterprises indeed do and will deploy both, for different reasons. What remains common, though, is that you want to be able to abstract network capabilities (what the network can do for the application) from how the network does it, and make that all policy-driven and instantaneous.

If you do, then "loosey-goosey" starts to turn "righty-tighty"...

Thanks Mitch!


sam masud 5/7/2014 | 4:33:34 PM
Re: Seems relevant FakeMitchWagner:

I keep hearing that the payoff with SDN will be lower opex, but given that SDN is the ITization of the network, are we in fact saying opex will be COMPARATIVELY lower with implementation of SDN (as opposed trying to do the same thing with traditional networks--e.g. service chaining)?
Mitch Wagner 5/6/2014 | 6:18:00 PM
Re: Seems relevant I don't see intelligence residing in the switch or controller as an either/or, but rather a spectrum. 

For the encroachment of IT into telco, how about "datacentrification?"
Mitch Wagner 5/6/2014 | 6:16:00 PM
Re: The Three Faces of SDN Yes, if SDN does take off we can expect to see it on new areas, while legacy networks continue to be maintained. As long as something is working and fit for purpose there's no sense ripping it out and replacing, even if the new thing is better. 
Page 1 / 2   >   >>
Sign In