“Why did it take people so long to invent the wheel? How did they not notice that round things roll?”

An interesting question from my daughter (who is NOT pictured above!), I thought, and it mirrors comments I’ve heard before that highlight what I believe is a misunderstanding about what the “invention” in question actually is. My daughter’s question seems to imply that what was invented was the circle (or at least, round things). In actual fact the a wheel is not just a round thing, it’s a round thing with an axle; without the axle, it’s useless. The invention was to take a round rolling thing, cut a hole in the middle and put a stick through it so that you can have a rolling thing attached to a static thing. That is a wheel, I explained to her. It was reassuring to check later and confirm that the dictionary agrees with me:

This led me to wonder whether we miss the point about other things too, and especially – of late – about the rapidly growing monster that is Software Defined Networking (SDN).

Inventions

What is the invention that we’re so excited (or fearful) about with SDN? Maybe I could list a few things that it’s not:

• Python
• Openflow
• OpenDaylight
• OpenStack
• OnePK
• Open vSwitch
• Some other things beginning with O
• ACI
• Affinities

None of these are the invention. I’d argue that conceptually at least, all these things existed in one form or another before being stamped with the SDN label. Looking at the example I gave of the wheel, it’s obvious that round things, sticks and holes all existed before the wheel was invented. The magic was in putting them together in a functional way to produce something that is more than the sum of its parts.

The same is true of the Apple iPhone. When it first came out it was in many ways a magical device, but which bit of it was Apple’s “invention”? Well, pretty much every technology in use was already available. Touch screens weren’t new. Mobile processors weren’t new. EDGE cellular chips weren’t new, and so on. Apple’s genius was to put these things together in a new and exciting way to produce a market-defining device. The invention was really the selection and integration of things we already had in a more beneficial way (and I argued previously that this was Steve Jobs’ real genius).

SDN

Software Defined Networking feels much the same to me. As vaguely defined as SDN is, it seems to be an amalgam of technologies into something that is of more benefit than any individual component. For example, OpenFlow is wonderful – but in most cases it’s useless without knowing what you want to do with it and how you’re going to use it. Want to know about flows on your network? Perhaps you can tap into the a vSwitch and get some information from there to feed into your analysis? Perhaps information from Cisco’s ACI chips could be of use. But this is a lot of information to handle, so you’ll want some kind of tool to analyze it all and do something useful with it.

Plexxi

Plexxi provide a good example of this, with programmable switches (which also have some very cool optical topology capabilities).

To program the switches, there is a controller platform (Plexxi Control) that takes affinity information and turns it into programmable network behaviors. In order to integrate with other tools, Plexxi then has Plexxi Connect, which links with workflow engines and third party network analysis products like Boundary. The individual elements of this solution arguably already existed; the MPO connector isn’t new; programmable switches are not Plexxi’s invention; nor is the idea of a controller; nor Boundary’s network data analytics. Even Plexxi’s awesome optical topology isn’t new exactly: the implementation is unique but the 3D Torus topology isn’t, though on its own it’s nowhere near as cool as what Plexxi have created.

I love that Plexxi in this case have pulled together a group of technologies and figured out how to develop them and make them work together in such a way that we get an enhanced product out the other side. It’s probably fair to say that without all those pieces being linked together, there’s no product. It’s very Wheel, you know? When I first looked at the Plexxi solution – incredibly over a year ago now – one of the concerns I highlighted was what I called “The SDN Gap”, and I said:

“This isn’t just a Plexxi issue, but there’s a gap here. Defining affinities is a manual process; there’s not (yet) an ability to identify heavy flows in the network and offer them up to you as potential affinities. After all, if you ask a server admin what remote nodes their server talks to, you’ll often get no response. The same applies if you ask the application owners – each team knows what they need to know, but may not truly understand the flows involved, and that’s going to make the process of creating affinities a challenge in some environments.”

In other words Plexxi had most of a solution in place, but I was concerned that it was not self-sufficient enough on its own to be a great solution. With the integration of other products via Plexxi Connect to help fill in the gap and identify affinities and performance issues, as a solution this has a lot going for it.

3D Networking

I mentioned this in passing above, but things have moved on since my original post about the Plexxi Switch 1. The predictably named Plexxi Switch 2 now provides additional LightRail™ MPO ports which means you can now have an optical mesh containing rings of rings. This is the small scale example I gave in my previous post:

In this case there are two rings containing four switches each, and the rings are connected together are two points (Switch 1–5 and Switch 3–7). This underplays the complexity that can be built given that a default Plexxi ring using Switch 1 models with two LightRail™ ports can contain eleven switches, each one having 20Gbps optical connectivity to all of their ten neighbors. The Switch 2’s additional LightRail™ ports mean that you can still have the eleven-switch, 20GBps peered optical mesh (physical ring topology) but you can now connect rings together. Switch 1 and Switch 2 can be mixed interchangeably, so you can just put a Switch 2 where you need interconnection, and put Switch 1 where you just need a ring member. Since each of those LightRail ports is a 12-way MPO with 2 10Gbps lambdas on each fiber, that’s not a small potential link between rings, and because of the way Plexxi does optical switching, you can stretch your optical paths even further between rings.

FlexxPorts

I love the double-x on “FlexxPorts”, by the way. This isn’t SDN as such, but since I’m mentioning Plexxi I may as well throw out there that the other rather neat idea that Plexxi through into the ring was to give direct – non-Ethernet – access to the optical fabric to link FlexxPort to FlexxPort. Or re-map fabric ports to FlexxPorts to extend the fabric that way instead. Neat.

Back to SDN

I didn’t start this post intending to talk about Plexxi, but as I continued with the analogies it became obvious that Plexxi was a great example to share. What Plexxi have done is “invented” a solution composed of a bunch of little pieces each of which in itself should not really be called SDN any more than using an expect script to login to a router is SDN. However, when you start pulling simple pieces together in clever ways, the potential power of the Software Defined Network really strikes home and it starts to become obvious how the data center of the future will be able to offer more intelligence than we could have imagined just a few years ago. Far from moving the intelligence to the edge and into the compute platform, these kinds of solutions push the smarts right back into the center of the network.

The network becomes a almost like a dynamic hub for the big wheel of connectivity around it. We shouldn’t be scared of that any more than we are of riding a bicycle.

 

Disclosures

I should add this since I ended up talking about Plexxi: Plexxi was a paid presenter at Networking Field Day 5 and Networking Field Day 7, and while I received no compensation for my attendance at this event, my travel, accommodation and meals were paid for by Tech Field Day. I was explicitly not required or obligated to blog, tweet, or otherwise write about or endorse the sponsors, but if I choose to do so I am free to give my honest opinions about the vendors and their products, whether positive or negative.

Please see my Disclosures page for more information.