It's not news that networking pros want to hear more stories about SDN deployments -- the good, the bad and the ugly. But as Gartner analyst Andrew Lerner points out in a new blog post, organizations and vendors are particularly hesitant to broadcast their networking failures. That's why Lerner issued a call for readers to share their stories of software-defined networking (SDN) disasters, so they could help others avoid similar pitfalls.
Lerner writes that most SDN failures he is aware of have happened in trials or proof-of-concept testing, rather than production deployments. In some cases, the product suite:
- Failed at scale;
- Failed to meet users' feature requirements;
- Lacked maturity; and
- Was too complicated.
Some organizations also reported that their networking teams were unprepared for SDN deployments, reflecting a need for cultural shifts and staffing changes.
In contrast, Lerner says that mainstream production deployments have fared much better --being relatively small, controlled and pragmatic.
Read Lerner's full post here.
SDN and NFV economics
In a recent post on "SDN World Series," blogger Jamie Davies talks to network engineer Brett Brock about what's holding back network functions virtualization (NFV) and SDN deployments.
Brock says the primary limiting factor is economic, pointing out that if SDN and NFV succeed in significantly reducing capital expense and operating expense for service providers, vendor revenue will shrink. Vendors will then find themselves with fewer resources to invest in software-first strategies, which could, in turn, slow the development of SDN and NFV.
Brock says the technologies represent more than just evolution for the sake of evolution, citing their potential to increase flexibility, scalability and operational speed -- even as they reduce costs. He notes, however, that NFV and SDN implementation typically require substantial initial investments, which could deter users.
To hear Davies' and Brock's perspectives on the role of open source in accelerating adoption, check out the full post here.
Do software-defined networks need fire marshals?
Networking pro Tom Hollingsworth writes on his blog that too many network engineers currently function as firefighters, fixing crises as they arise. He says that networks also need fire marshals to evaluate existing risks and prevent future meltdowns.
Hollingsworth suggests that each organization should designate one person to investigate why past network failures occurred, and how future disasters can be avoided.
Hollingsworth writes that SDN -- anchored by increased visibility, agility and automation -- will help prevent network fires, but on its own isn't enough. Investigation, education and forethought are key to transitioning from a disaster response mind-set to one of disaster prevention.
Where do enterprise SDN deployments stand?
open networking could dramatically reduce Opex and Capex
Using network management to avoid network crises