Fotolia

News Stay informed about the latest enterprise technology news and product updates.

Five reasons some SDN deployments fail

In this week's roundup of blog posts from around the Web, a Gartner analyst shares five common reasons for software-defined networking meltdowns.

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:

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.

Next Steps

Where do enterprise SDN deployments stand?

Open networking could dramatically reduce Opex and Capex

Using network management to avoid network crises

PRO+

Content

Find more PRO+ content and other member only offers, here.

Join the conversation

1 comment

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

What SDN failures have you witnessed, and what caused them?
Cancel

-ADS BY GOOGLE

SearchNetworking

SearchEnterpriseWAN

SearchCloudProvider

SearchUnifiedCommunications

SearchSecurity

SearchDataCenter

Close