The OpenDaylight Project has hired former VMware cloud strategist Nicolas "Neela" Jacques as its executive director....
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
OpenDaylight is an open source Linux Foundation project launched by several leading IT vendors and aimed at creating software that can serve as the foundation for future SDN products and research.
Jacques takes the helm just weeks before OpenDaylight is set to release controller code that it hopes will become an industry standard and central to most vendors' SDN strategies.
As executive director, Jacques will support, facilitate and magnify the efforts of the developers who are working on the OpenDaylight Project, he said.
In this Q&A, Jacques discusses some of the challenges and opportunities that OpenDaylight will face as it tries to push SDN forward.
Why did you take this job?
Neela Jacques: Over the last few years [at VMware], customer after customer kept telling us that networking was standing in the way of having a more efficient, more automated, more standardized DC [data center]. It led to VMware acquiring Nicira to bring a solution to that problem to market. No one is saying that network virtualization and SDN aren't the way to solve these problems, but there are a number of major inhibitors to this change occurring. The big one is the interconnectedness of networks. Every vendor in this space is coming out with solutions … but [each vendor] is telling a story about how everyone else is going to connect into [their SDN platform]. Maybe one or two of them is going to win that battle, but [this dynamic] is freezing the market. If you're a customer faced with five, 10 or 15 vendors trying to sell you on their vision, how to do you pick one?
The SDN controller is, for the most part, a commoditized system. That's not where the differentiation is occurring. It comes in the management and in the virtualized services on top of it, or the equipment underneath. In industry after industry, when there is a need to come to a common platform, open source was the dominant way that was done.
When OpenDaylight first emerged, some people said it would freeze the industry because many potential SDN customers would stall their buying plans to see what unfolded. How does OpenDaylight actually 'unfreeze' the industry?
Jacques: On the one hand, the market is going to say, 'Player X, you are far superior to everyone else. We're only going to buy you.' And someone gets 90% of market share, like VMware did six years ago. That creates a standard, and an ecosystem is created around [it].
Otherwise, you need cooperation. In networking, an idea or white paper often isn't enough. People want real code that they can build around. With OpenDaylight, you have over 100 developers all contributing code to this project, debating with each other -- not with ideas but with actual code.
A number of startups in this space look at the market and know they have to put their first 10 to 15 developers to work on a controller. They say, 'I wish I could just grab one off the shelf, because my differentiation isn't in the controller but in all the services I'm building on top of it.' Once that code is out [from OpenDaylight] and matured to point that they can use it, [many companies will] abandon their own controllers and just adopt the industry-standard one.
On the other side, you have major players out there looking to incorporate OpenDaylight into commercial products. The reason for that is some of their largest customers are saying, 'I want open source.' They're not saying they want a free product. They're saying, 'I would like a product where I and everyone else can actually see the code. Where I can have my smartest engineers look into it and see how this thing is architected or engineered, and if I need to make a change, then I could make the change.'
Jacques: There are two flavors of controllers out there. There are general purpose controllers and specific purpose controllers.
In a general controller platform, there is a basic functionality. You create a controller that speaks OpenFlow. As other standards come up, it can speak those, too. It can talk to old switches and have master routing information. That is the part that is commoditized.
There is a different class of controller built to solve a specific problem. Contrail is a good example. It is not an alternative to OpenDaylight; it's a different animal, and in fact those two can work closely together.
[OpenStack] has some level of network functionality in Neutron, but it's not actually competitive to OpenDaylight. So in fact you have had efforts to bring the two projects together. You have developers who are working on both projects simultaneously, and this is something you would only see in the open source community.
You mentioned controllers that are built to serve a specific purpose and contrasted OpenDaylight with Contrail. As a user, why would I want to, and how would I, use both?
Jacques: Let me give you a generic example. The OpenDaylight controller is just [an SDN] controller. It doesn't create an overlay for you. It's doesn't manage your network. It is one place that your switches can call to get routing information and so forth.
There is a huge need for a new way to manage networks. There are two approaches: the Insieme approach with Application Centric Infrastructure and the other approach -- network virtualization and creating overlay on top. One of the things [Contrail] allows you to do is create virtual networks that then integrate with the physical underlying network.
If you've got a new project, you want to create a network for that project that is encapsulated in a logically abstracted network and that gets translated into the wide range of functions that need to happen so that those packets flow onto the physical network. That isn't something that's done by the OpenDaylight controller. If you implemented Juniper's Contrail solution with OpenDaylight, you get those management tools, and you could go in and create a network for Project X. Then that management tool is going to plug into the OpenDaylight controller and code the lookup tables so that when the switches and routers make calls up to the controller, it's giving the right information and the packets are delivered in the right way and can cross network boundaries when they're needed.
Obviously Juniper can deliver Contrail by itself. That works really well if you want to live within that one vendor's architecture and ecosystem. The challenge comes … if you want to buy Juniper functionality and [combine that] with Cisco functionality and IBM functionality. What you'd like is all of that to come together in one central place, rather than having three things that were primarily designed with the thought that they were going be the central component of a system. Everyone says, 'I work well with everybody as long as everyone just plugs in to me.' Open Daylight provides that control point built by a neutral third party that's thinking about what's right for the end user rather than trying to figure out how to lock people into your own black box.
When the OpenDaylight code release comes out at the end of the year, will we see products based on this technology?
Jacques: Absolutely. On the one hand, you'll have large vendors releasing products based on it. You'll see smaller companies incorporate this and abandon internal competing efforts. You'll also see some great activity from new startups … [that] say, 'I can get a viable product built much faster if I get [my] team to leverage this million lines of code that [are] already contributed to the project, rather than creating yet another controller that does the same stuff.'
Any change like this is going to threaten some people. The open source model is very unknown to many people in the industry. You're going to see healthy debate of people criticizing every part of it -- that it's too dominated by this vendor or not dominated enough by this person. [They will say] there aren't enough end users involved or that end users are dictating what they want too much. Every side of every issue is going to be aired publicly. But that just shows how much people care.
How do you prevent proprietary interest from winning those debates? There are critics who say this project is dominated by Cisco and IBM and companies allied or dependent on them. For instance, IBM is a tremendous sales channel for Brocade and Juniper.
Jacques: You always want to be vigilant. I heard the same criticism. I met with a number of board members and I met with a number of the developers. I was looking at whether people were working in the short-term best interest of their employers versus the bigger-project vision. What I found was [those] on the developer side associated themselves [first] with the project and thought second of the larger vision and strategy for their employer. That's not to say those are at odds, because I think the reason that many of these people are contributing is because there is belief that industry is changing, and they need be a part of that.
One developer I talked to was working with Cisco when I first spoke to him. By the second or third conversation I had with him, he was working for Red Hat. I asked him what changes for him. He said not much. He is one of the key guys working on that core SDN controller. We have such a vibrant community because people are viewing the larger interest, and for the most part we've seen the vendors not try to bring tremendous influence in there.
One testament to this is [my selection as executive director]. In the bylaws, the platinum vendors have the right nominate or bring forward one of their employees to be executive director. If you wanted to really control this project, you could see a vendor nominate an employee. That would be a silly thing do, because the success of the project is based on the world viewing it as truly an open source project. I think there are a number of people who are on my board who, if they wanted to control [OpenDaylight], might have picked somebody from a different organization [rather than VMware]. [But the main criteria was to find] someone to serve the needs of the community and the needs of the developers. What I hear over and over again, from developers to the CTOs [chief technology officers] of these companies, is that we have a shared belief in terms of what needs to happen in the industry.