Thursday, October 10, 2013

OPENDAYLIGHT DEVELOPER SPOTLIGHT: David Lenrow [feedly]


 
 
Shared via feedly // published on OpenDaylight blogs // visit site
OPENDAYLIGHT DEVELOPER SPOTLIGHT: David Lenrow

OpenDaylight is an open source project and open to all. Developers can contribute at the individual level just like any other open source project. This blog series highlights the people who are collaborating to create the future of SDN.

David Lenrow is the Director of Product Strategy at Plexxi and an active contributor to the OpenDaylight Project. He was trained as a computer scientist and has spent more than 20 years driving innovation in digital technology with an emphasis on networks, storage and media. His career spans multiple roles from individual contributor to executive across all major functional areas in technology companies. He is passionate about innovation and seeking to make contributions to the cloud revolution currently sweeping the tech industry.

How did you get involved with OpenDaylight? What is your background?

I spent many years as a network equipment developer, architect and manager. I'm now a sort of hybrid architect and business guy, currently in a strategy role in Plexxi's product management group. I've been learning all I can about SDN since reading about the OpenFlow work at Stanford in 2009. I immediately saw that the approach, if not necessarily the wire protocol, had potential to unleash innovation in an industry that had become "fossilized" (as my friend Tom Nolle likes to say). When there was an opportunity to combine my passion for SDN with an open source community that could change the game, I pounced on it.

What project are you working on for OpenDaylight? Any new developments to share?

I'm working on some code to translate the "intent" expressed by Affinity Metadata into rules to implement that intent in forwarding devices. I'm also involved in design discussions about several critical architectural decisions pending in the community. Specifically we are trying to figure out :

  • What is policy and what form does it take? How do we arbitrate policy among modular SDN services developed independently?
  • How do we make it easy to extend and adapt the intent attributes that our affinity service can support?
  • How do we make the tradeoff between consistency and availability of distributed state when the network is partitioned?
  • What are common elements of the disparate southbound APIs and protocols that might be exploited to allow applications to support multiple plugins in a more portable manner?

People have different definitions for SDN depending on how they're using the network. What's your definition of SDN?

I think we need to move past talking about SDN, which is essentially a tool for building stuff, and talk about what we are building with SDN. If you're shopping for a home, you want to know how many beds and baths (and location, location, location), not whether the builder used a hammer or a nail-gun. The number of people who want to "program their network" is several orders of magnitude smaller than the number who want to exploit the benefits of programmable networks. It's the vendor's job to figure out what those benefits are and deliver them. Some of the most obvious benefits in my mind are the ability to hide operational complexity, increase workload and policy portability and make systems integration less of a burden. Plexxi delivers such benefits in our commercial products and our work in OpenDaylight is spreading those benefits more broadly.

From your perspective, what are the major benefits of making OpenDaylight an open source project?

The specific governance policies within OpenDaylight and the Linux Foundation ensure that decisions are reached by merit and collaboration, rather than political tricks and market-share. Interests are aligned because all the contributors want to get a robust, scalable, high-performance platform upon which they can build their unique value add. It's quite amazing to see competitors collaborating smoothly, while knowing they will be on opposite sides of the line of scrimmage on game day. Vendors and end users alike can feel confident that they control their own destiny, because the source code is available to study and to modify. Operators can provide oversight that keeps the vendors honest; I could go on and on.

What will the SDN landscape look like five years from now?

The vendor ecosystem will look more like the PC industry and less like the mainframe industry. It will take a while to get to the "app store" model ("who the hell downloaded Angry Birds onto our high frequency trading network?"), but I could see something similar to the enterprise software market emerging soon. I'm not sure there will be a traditional closed-source-only juggernaut like Microsoft has been in PC software, but I could easily see a bunch of folks making the Red Hat model work.

What advice would you give to someone just getting started in an open source project?

All the cliches. Love what you do. Listen more than you talk. Sit up straight. Eat your vegetables. Go for long runs when you're too brain-dead to write any more code, then hit it again.

What is your favorite quote from the old closed-source universe?

We're a year ahead of the competition, but if they ever get hold of our source code we'll be two years ahead.

 






Sent from my iPad

No comments:

Post a Comment