Floodlight Use Case: Software-Defined Storage

Our friends at Coraid used Floodlight to demo a Software-defined-storage use case at this year’s VMWorld 2012 in San Francisco.

Alok Rishi, Coraid’s Chief Software Architect, showed how one could use Floodlight’s v0.85 REST APIs, controlled programmatically via the Ethercloud orchestration stack, to dynamically create isolated data flow paths end-to-end:  through the Coraid storage targets, through the Coraid initiator, then onto the VM.

We are especially excited about this demo because:

* the integration combines both virtual switches (OVS + Xen) and physical switches (openflow-enabled Arista)

* EtherCloud is controlling Floodlight entirely through REST APIs.

* the entire demo was set up in just a few days

* the demo also showcased the Avior Floodlight GUI application written by Jason Parraga

This is just one example of creating value by combining SDN controller + cloud orchestration stacks + storage +  OpenFlow enabled switches. We would love to hear more examples and ideas from you.

A block diagaram of the setup can be seen here:


Here is Alok performing the demo at VMWworld:


From left: Mike Cohen (Big Switch), Alok Rishi (Chief Architect, Coraid), Paul Lappas (Big Switch), Doug Dooley (VP Product @ Coraid)



Floodlight Update

My colleague Mike Cohen has done an amazing job growing and evangelizing Floodlight since  launch earlier this year. I wanted to relay some of the notable facts are:

  • Over 6,000 downloads since January 2012
  • A Google search on “floodlight” returns this project as the first natural result
  • Downloaded by IBM, Arista Networks, Brocade, Dell, Fujitsu, HP, Intel, Juniper Networks, Citrix and Microsoft.

To continue Floodlight’s meteoric growth, we will be spending the next few months focusing on tools and processes to promote quality and collaboration:

Testing Framework

The goal here is to target 100% automated test coverage of the project by releasing a good test execution framework and set of automated tests.  This is so that when you add a change you can be sure that your new code didn’t break existing functionality, and fix any problems before you submit a pull request to get your changes in. Of course this means that you as a developer will also need to check in a test with your changes.

Better transparency

In what features are proposed, features being worked on, and the scope of the next few releases (roadmap). As someone with a background in delivering large scale projects on time and budget, I know how important it is to have visibility into what’s working and what’s coming. This is so that potential developers know where they are needed most

Coding style and standards

Obviously important that we can set up guidelines for implementation so that the code base can grow in a way that is well understood and sane.

And much more to come!

Doubling-down on OpenFlow

I’m incredibly happy to announce that I’ve joined to help lead our efforts around open source, including Floodlight, the world’s only apache-licensed SDN controller, and Indigo, an OpenFlow agent for physical switches.

First, a little bit about me:

In 2006 I co-founded and ran engineering and operations for GoGrid (www.gogrid.com) , one of the world’s first cloud computing service providers. After growing GoGrid to span two continents and service over 10,000 enterprise users using only open-source tools (and what was at the time the second largest Xen deployment next to Amazon EC2) I decided to refocus my efforts on where I saw most of the adoption of cloud would be happening:  private deployments inside of enterprises providing automated self-service to internal development and IT groups.  I ended up helping Piston Cloud (www.pistoncloud.com) – who was building a distribution of OpenStack – bring their product to market, until my friend Kyle Forster @ Big Switch told me that he was looking for someone to help grow out their open source efforts that include Floodlight and Indigo.

Now, I had been keeping my eye on OpenFlow and SDN since 2007 when Martin Casado pitched us his idea to connect virtual hosts via dynamically provisioned (what were then GRE) tunnels when we were trying to figure out how to scale the GoGrid network (we decided the technology was too immature). So my first reaction to Kyle was “why does Big Switch need an open source strategy?”. After all it’s no secret that it’s very difficult to make money selling open source technology. Not saying it’s impossible – obviously companies like Redhat have found the secret – but unless your market is gigantic and product is extremely easy to deploy and support, it becomes very difficult to turn a profit. And as a startup in the incredibly competitive enterprise infrastructure market and competing with a giant like Cisco, you could say I was “cautiously intrigued” by the idea.

I wanted to be sure that Big Switch was serious about doing what it takes to truly create a vibrant open source community – the most important attribute of which is a diverse set of contributors who are not dominated by one company or influenced by commercial interests.

After spending a few weeks with the team, a few things became obvious:

— Big Switch’s commercial products have an incredibly compelling value proposition (hint: it’s all about the Apps)
— Floodlight represents the “core” of the commercial product (that is still in Beta), and
— with Floodlight, we have the opportunity to define the de facto standard for controller APIs
— we have assembled the best engineering team for SDN in the world

I look forward to diving into this in much more detail as we become more public about our plans, but I can say that I’m incredibly excited about the opportunity that we have in front of us, and what this means for developers and users of SDN technologies as we disrupt the world of network infrastructure.

You can reach me anytime at paul.lappas@bigswitch.com or email to the floodlight-developer group.