Manage Learn to apply best practices and optimize your operations.

Will the Facebook switch and SDN OS change networking? Maybe

Network engineers are largely split on how the new open source Facebook switch and SDN OS will impact their environments.

In June, Facebook announced intentions to open source the forwarding agent for FBOSS, its SDN switch operating system, and Wedge, its bare metal switching hardware.

Most of us know that hyperscale operators have been quietly deploying bare metal switching hardware and pairing them with SDN operating systems for the past few years. Facebook's announcement follows Google's Andromeda networking platform and earlier leaks about its Pluto switch.

Already these launches -- and the release of other white box switches -- are having an impact on switching market share. In fact, Alan Weckel at Dell'Oro Group reports that shipments of bare metal switching represented slightly over 10% of the Fixed Top-of-Rack 10GE switching ports at the end of 2013, more than Arista, Juniper and Extreme combined.

The key question facing the networking community is: will these hyperscale networking technologies spread to the rest of the market or are they a unique phenomenon?

To be sure, the Facebook announcement has ratcheted up the interest of the community into hyper-drive (pun intended) and so I took this opportunity to talk about the news with a number of network architects to see what they thought of the potential impact.

For context, I believe most of us in the networking community agree that the design challenges of hyperscale data centers are different from traditional data centers. An analogy I like is that designing a hyperscale data center network is like training an elephant -- you focus all of your energies on the needs of one piece of software. But designing a traditional data center network is more like managing a zoo -- architects balance a diverse set of applications with diverse heritage and diverse needs, but all are sharing the same infrastructure.

Beyond noting the clear difference in hyperscale vs. traditional data centers agreement, it has become clear that there are three camps when it comes to network engineer reaction to the Facebook Wedge and FBOSS announcement.

First camp: Ready for the Facebook switch and SDN OS today

There are those who want FBOSS and Wedge as-is for their data centers. These companies have software development teams that build in-house control/management systems, and "initial turn-up and decommissioning, upgrades and downgrades, draining and undraining (as Facebook refers to it)" are problems they like to solve on their own. So, for an established networking software dev team, FBOSS is a new software component that they want to use immediately.

Second camp: Wedge and FBOSS are great, but packaged management is a must

Then there are those who want to try something like the Wedge/FBOSS approach, but want the control/management systems packaged and ready for consumption by a traditional networking team. Rather than design an entire data center network all at once, this camp has tended to look to specific projects -- OpenStack, VDI, Big Data -- to justify a new network design. These organizations tend to have strong network engineering heritage and an early adopter bent.

Third camp: Wedge and FBOSS only for the hyperscale, not general enterprise

The last camp thinks that news like this represents a hyperscale phenomenon and not the start of a larger trend. Not until they see more adoption by the community at large do they really start paying attention. This camp leans traditional, meaning that incumbent vendors will have a business here for a long time.

The takeaway

What do I think? The Facebook crew behind this is a very smart team and a very busy one. Its members wouldn't go through the trouble of turning a well-run engineering project over to a chaotic open source democracy unless they were looking to steer a broader networking community down a path that is very different from the one set forth by incumbent networking vendors. I tend to believe that when the high-end networking users show this sort of leadership, the broader community will follow over time.

Good on 'em -- can't wait to see what happens next.

About the author:
Kyle Forster is Co-Founder of Big Switch Networks.

Next Steps

Dell bare metal powers Big Switch SDN

An expert's take on whether enterprises need white box switches

Bare metal switch basics: A guide

Cumulus unveils a Linux-based network OS

A new open source SDN switch emerges: LINCX

This was last published in July 2014

Dig Deeper on Software-defined networking

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Will the Facebook switch and SDN OS change the way you design your data center network?
We are reviewing these possibilities. If there is any impact, we won't make any design changes for at least 2-3 years.
I think the conclusion that people will follow is correct. Whether they follow a specific instance of networking or just adopt new architectures is almost unimportant. That there will be change seems evident.

The question I ask is how everyone will react to the change. What will be the catalyzing event that gets people over the hump? CapEx by itself is not enough to get people to change their tools, process, and people. So what follows from this architectural renewal that allows people to do things that they wish they could do but currently cannot?

IMO, narrow deployments that do something specific will be the easiest way for people to say yes. Big Switch's tap application, for instance, is a narrow use case that is very specific and easy to say yes to. It's not surprising to me that there is traction there. What other use cases will follow?

When those use cases follow, you will see more people make the leap. And when that happens, we might hit some collective tipping point that disrupts things in a permanent way. I wouldn't count out the big guys in all of this; they can certainly adopt a similar strategy. But the challenge there is that these narrow use cases have even narrower business cases, making them difficult to sell internally.

Fun times for sure :)

Mike Bushong (@mbushong)