Plexxi has an interesting problem. They have a shiny new solution that requires unorthodox approaches to network forwarding and allows them to implement potentially cool concepts like affinities (traffic engineering in disguise). They also need to sell these new concepts to the customers, and the first question I would ask after recovering from a hefty dose of cool-aid is "and how do I configure these affinities?"

They might have tried answering "our ecosystem of partners allows our controller to collect the relevant data and use advanced visualization capabilities to present the underlying affinities", and risk being thrown out by anyone with marginal operational experience. They might have written spaghetti-like integration modules for vCenter, System Center, vCloud Director, OpenStack, CloudStack, SolarWinds, OpenView … Fortunately they decided to do something else - develop a solution that just might work.

Before going on, you might want to watch the Plexxi DSE video from Networking Field Day 6.

Done? OK, here's a brief summary of what DSE is: it's a message bus (a glorified name for a chat room) with plenty of data normalization modules (think regexp-based scraper, but better) that allows whatever existing systems you have to exchange data. Obviously someone has to write the integration modules, but it's much simpler to do that than to develop several almost-identical 1:1 solutions without an underlying common architecture.

Having a unified architecture for data collection is cool. Having a message bus is cooler - it allows anyone on the message bus to hear the messages sent by anyone else (a fact commonly exploited by IRC trolls). Plexxi has given us generic orchestration architecture while solving their data collection problem … and following the great examples of Facebook, Google and Netflix decided to open-source it.

Why am I writing about it?

You did get the idea that any module could listen to any other module, right? Here are just a few things you could do with that functionality:

• Collect data from your cloud management platform (or vCenter/System Center) to change load balancer pool definitions;
• Use that same data to change access restrictions in your database server;
• Use that same data to provision your firewall (read also Brandon’s post on the same topic);
• Use event log from load balancer to spin up additional server instances or change traffic patterns;
• Use network utilization data to shut down unnecessary parts of your application in overload/DoS scenarios;
• Have a central repository of troubleshooting data (IP addresses, MAC addresses, VLANs, VM names, groups …) that just might help Derick find that phone he’s still obsessed with (you did watch the video, did you not? Here’s another hint).

I'm positive you'll get at least a few additional creative ideas - share them in the comments!

I know you can do any (or all) of the above with whatever set of incompatible point solutions that don't talk to each other, but here we have an architecture that allows us to do it in a clean and somewhat manageable way.

Disclosure

Plexxi was a sponsor of Networking Tech Field Day.

Also, I might be a bit biased, so think twice before you jump into SDN waters.

More information

I would highly recommend that you start reading Plexxi blog (although I don’t necessarily agree with everything they write). You can also watch Plexxi presentation from Data Center Fabrics webinar.