----
OpenDaylight Developer Spotlight: David Goldberg
// OpenDaylight blogs
OpenDaylight is an active community of developers who are passionate about transforming networking. This blog series highlights the people who are collaborating to create the future of SDN and NFV.
David Goldberg is ConteXtream's lead software engineer and was the first software developer to join the next generation SDN product team. David is also leading ConteXtream's contribution to the OpenDaylight project and is one of the top commiters to the LISP Flow Mapping project. Prior to Contextream, David was responsible for the development of network analysis tools during his army service in an elite technological group in the IDF Intelligence Corps. David holds a BA in Computer Science and Management (cum laude).
How did you get involved with OpenDaylight?
I got involved with OpenDaylight when ConteXtream decided to base its next generation SDN on open standards and open source emerging in the field. We at ConteXtream believe that an open source and open standards approach to SDN and NFV is the way to achieve a scalable and programmable infrastructure that operators are looking for. This will ensure standardization through a common infrastructure that everyone will use. The advantage of OpenDaylight as an open source project is that everyone can join and help develop the controller. There is no doubt that it will become the best SDN controller in the market. We joined the OpenDaylight project to help create the foundation for our second generation carrier-SDN solution.
What project in OpenDaylight are you working on? Any new developments to share?
I am glad to be part of the Location Identity Separation Protocol (LISP) Flow Mapping project. This is a project we specified together in an Request for Comment (RFC) draft that extends the LISP for use in SDN/NFV. The specification part was with Cisco, Lispers, Brocade and OpenDaylight's David Meyer, and the LISPMobile open source group. We started coding together with Cisco and LISPMob. The idea was to contribute distributed federation to SDN control which is standards based. We knew from our experience in carrier environments that such federated scale and resiliency for SDN edge-over-IP is a must. We used the OpenDaylight controller as a LISP map, meaning that network devices that use the LISP protocol can use it as their pull, publish, subscribe global awareness service. We managed to reach a working version that supports most of the LISP protocol by the Hydrogen release, so the main part of the development is already behind us. We are now working on implementing the rest of the LISP protocol so that the OpenDaylight controller will be fully LISP-friendly. We also integrated with OpenStack's Neutron, so that OpenStack can provide virtual networking and virtual function orchestration, which applies network wide by communicating with the distributed mapping system.
OpenDaylight's first software release debuted in February 2014. What do you think is most important for the project to focus on for the next release?
I think that the two most important items that we should focus on are stability and performance. Now that we have an official working version out, we want to spread the word to as many network developmers and companies as possible, so that they will adopt OpenDaylight as their controller. In order for that to happen, we need the controller to be stable and fast. It's something the community is working on, and there is a team dedicated to improving its performance. It was also one of the main agenda items of the March HackFest.
Fast forward five years: where do you see OpenDaylight?
I think that the OpenDaylight controller will be the base of most SDN solutions in the market. The industry has already started to understand that openness is the key for every good networking solution, and OpenDaylight provides an SDN common platform. When I create a product based on OpenDaylight, I know that I will be able to run it on all of the solutions based on OpenDaylight, which is a big advantage. It is also true from the side of the SDN solution. When I create an SDN solution, I will want to build it based on OpenDaylight, because I know that I will be able to integrate with many other products which work with OpenDaylight, and that's what will make OpenDaylight the future of networking.
What is the biggest challenge facing networking today and how will SDN and NFV resolve it?
In the last ten years we have seen a huge growth in network traffic both for mobile operators due to the wide penetration of smartphones and use of mobile apps, OTT video and regular data service consumption due to Netflix and HD video streaming and downloading. Thus, operators need to find innovative ways to optimize their expensive infrastructures, reduce churn and monetize the growing traffic. SDN and NFV enable the creation of a distributed SDN fabric on which operators can overlay a variety of network functions to deliver subscribers a given service. It enables NFV solutions like video optimization which can reduce the amount of traffic in the network. We can also use the same hardware for different network functions using load balancing to make sure that we always have enough resources for each network function. This will reduce the total amount of hardware needed for redundancy from 1+1 to N+1, which in turn reduces the cost for the operator. SDN and NFV will revolutionize the way we do networking today.
What is the best piece of developer advice you've ever received?
"Don't reinvent the wheel." As a software developer, we sometimes think we can do everything ourselves. If we need some piece of code, we can just write it. This may work if we have infinite time and know everything there is to know, but in the real world, we want to focus on our advantages and on our core business. Almost every software problem we are facing was probably solved sometime in the past, and was reviewed by many experts and perfected since then. We can and should just take it and use it. This is even more so in the open source world, where the code is out there for everyone to use. We should always look for a solution out there, before writing some utility of framework ourselves, and that way we can totally focus on what we know best, which is the core business we are developing.
----
Shared via my feedly reader
Sent from my iPhone
No comments:
Post a Comment