Thanks to the person who asked me about the Daylight Project via a blog comment. I’ve been researching the rumors online. The purpose of this blog is to summarize the consistent (leaked?) themes, particularly for those who haven’t been watching SDN closely. And sneak in some thoughts of my own. I’m writing this while in San Jose, where you never know, one or more of the Network Field Day 5 vendors might drop some hints. If I write about Daylight beforehand, we can all be assured that I won’t run into any NDA issues. Nothing but the best rumors here!
I should note that fellow NFD5 attendee Brent Salisbury blogged about Daylight back when it was breaking news. See http://networkstatic.net/more-vendors-define-their-sdn-strategy/.
Per the first two reference links below, Daylight is a SDN group with Cisco, IBM, HP, Citrix, NEC, and BigSwitch as members. The group is producing open source software, following the Apache and OpenStack models. The code will be an OpenFlow capable controller with Citrix service chaining code and HP code for L2 services. It will have high availability and clustering capabilities.
Public announcement is expected in April at the Open Network Exchange conference.
Per the Network World article below, Juniper commented in general reflecting its own SDN approach, and would not indicate whether it was joining the Daylight group. If I’d just spent a lot of money on my own solution and gearing up to market it, I too might not want to comment.
I enjoyed the commentary in the SDNcentral link listed below. “This should reduce the number of SDN platforms / controllers you may have to write to.” Definitely. Good thing, too.
To this observer, right now the whole SDN and OpenFlow arena seems characterized by way too many VC-funded startups. Might we call this a “VC bloom”, by analogy with the algae blooms you get when there is too much nutrient in a pond? I’d much prefer to see innovation around a common core than a lot of underfunded and/or struggling efforts, each with their own unique value and twist but lacking the power of full core functionality.
I used to wonder about all the forks in Linux code producing different variants. Was it really wise to split the people and coding energy across so many variants? I recall the joys of trying to get a package from X that allegedly supported variant Y but was built on Z to actually compile and run properly. Colossal waste of my time. (And rarely had the time to actually get stubborn network management packages to work.) Linux has at least converged to a few big players now. It is far too early days for such convergence in the SDN world.
The SDNcentral link goes on to say that one purpose of Daylight is to provide a VMware / Nicira alternative. That may be. In my SDN reading, I’ve been getting the feeling that various vendors have been trying to take SDN in a direction that matches their world view, or at least their business plan. That doesn’t necessarily produce a lot of commonality in terms of direction.
The simplistic version of that might be that hardware vendors want to … control hardware, VMware wants to control virtual machines and networks, and cloud vendors might want SDN to move you smoothly into their cloud (but not out or to a competitor). If you think about it, SDN might even be programming say Intel chips doing switching or other OpenFlow functions in hypervisor host NICs, rather than physically standalone OpenFlow switches.
One impression is that Cisco seems to be very interested in the hybrid cloud, perhaps because then they can sell you or your cloud vendor hardware. The flexibility of mixing private and public cloud then might be an incentive to use … Cisco hardware?
Per recent blogs about VMware’s antagonism to the cloud providers, is it likely that their tools will provide cross-hypervisor cloud support? Or is this a case of any cloud as long as it uses VMware?
Perhaps we could hope that the hardware vendors might take Daylight in a more agnostic direction, one where the controller supports provisioning vendor-specific hardware, OpenFlow or other platforms, and cloud platforms and whatever else evolves as well? Open source would be a good first step in that direction!
Optimistically, this gives up most if not all single vendor lock-in and provides a shared playing field for the vendors to compete with innovation. And yes, that’s arguably quite a bit better for the customer.
I’m not sure I buy into the idea some OpenFlow people have of generic hardware at low cost. With an open source controller and modular code, we can at least hope that Daylight might support migrating between vendors, to whichever one you choose in the future as meeting your performance / cost goals. I hope to have more to say on this aspect of SDN in another blog.
Links about Daylight
http://www.networkworld.com/community/blog/sdn-meet-sheds-little-light-cisco-daylight
Disclosure
The vendors for NFD 5 are paying my travel expenses and perhaps providing small gift items, so I wish to disclose that in my blogs now. The vendors in question are: Cisco, Brocade, Juniper, Plexxi, Ruckus, and SolarWinds. I’d like to think that my blogs aren’t influenced by that. Yes, the time spent in presentations and discussion gets me and the other attendees looking at and thinking about the various vendors’ products, marketing spin, and their points of view. I intend to try to remain as objective as possible in my blogs. I’ll concede that cool technology gets my attention! Stay tuned!
Twitter: @pjwelcher
(Disclaimer: I work for VMware/Nicira.)
Hi Pete, thanks for taking the time to share your views on the oft-rumored Daylight project and its potential effects on SDN. I did want to very briefly comment on your statement regarding VMware’s cross-hypervisor support. While it’s true that VMware’s server virtualization and associated products have been rather hypervisor-specific (although we are starting to see changes there), VMware’s network virtualization product–which came from the Nicira acquisition–is highly hypervisor-agnostic. Nicira was also pivotal in the development of Open vSwitch, which is also highly hypervisor-agnostic (works equally well with Xen or KVM). With regard to network virtualization, this is a trend that you won’t see changing.
Thanks!
Great! Thanks for setting me straight. I think you’re saying it’s a coop-etition (cooperate / compete) situation, as stuff around evolving . (Compete and cooperate.) That subtlety escaped me when typing the blog.