Faucet Deep Dive on Software Gone Wild
This podcast introduction was written by Nick Buraglio, the host of today’s podcast.
In the original days of this podcast, there were heavy, deep discussions about this new protocol called “OpenFlow”. Like many of our most creative innovations in the IT field, OpenFlow came from an academic research project that aimed to change the way that we as operators managed, configured, and even thought about networking fundamentals.
For the most part, this project did what it intended, but once the marketing machine realized the flexibility of the technology and its potential to completely change the way we think about vendors, networks, provisioning, and management of networking, they were off to the races.
We all know what happened next.
When the dust settled and there was a brash realization that the technology that was OpenFlow was not, in fact, the diamond encrusted Rosetta Stone that it had been so heavily marketed as, the interest had already withered.
Plagued by poor implementations, half-hearted support, terrible misconceptions, and a litany of other preventable issues, the projects associated with OpenFlow moved into the shadows, but some of them are still happily building and growing, improving support, and hardening their deployment model.
In the Episode 113 of Software Gone Wild we talked with Josh Bailey and Brent Salisbury - both heavily involved in the SDN controller space - about the common misconceptions. We tried to dispel some myths, and talked a little bit about the Faucet project, the scrappy OpenFlow controller that works, works well, operates at scale, and at speed.