It’s reasonably easy to add automation and orchestration on top of existing network implementation. Throwing away decades of field experience and replacing existing solutions with an OpenFlow-based controller is a totally different story as I explained in May 2013.

In the meantime, most projects trying to implement centralized control plane turned into abandonware – it turns out it’s too hard to reinvent all the wheels even if you’re a networking vendor or VC-funded startup – and Open Daylight got nowhere.

The OpenFlow zealots are quick to point out the beauties of the centralized control plane, and the huge savings you can expect from using commodity hardware and open-source software. What they usually forget to tell you is that you also have to reinvent all the wheels the networking industry has invented in the last 30 years.

Imagine you want to build your own F1 racing car ... but the only component you got is a super-duper racing engine from Mercedes Benz¹. You're left with the "easy" task of designing the car body, suspension, gears, wheels, brakes and a few other choice bits and pieces. You can definitely do all that if you're Google or McLaren team, but not if you're a Sunday hobbyist mechanic. No wonder some open-source OpenFlow controllers look like Red Bull Flugtag contestants.

Does that mean we should ignore OpenFlow? Absolutely not, but unless you want to become really fluent in real-time event-driven programming (which might look great on your resume), you should join me watching from the sidelines until there's a solid controller (maybe we'll get it with Open Daylight, Floodlight definitely doesn't fit the bill) and some application architecture blueprints.

Till then, it might make sense to focus on more down-to-earth technologies; after all, you don't exactly need OpenFlow and a central controller to solve real-life problems, like Tail-f clearly demonstrated with their NCS software.