• 05/01/2014
    8:00 AM
    Bob Laliberte
  • Bob Laliberte
  • Commentary
  • Connect Directly
  • Rating: 
    0 votes
    Vote up!
    Vote down!

Buy Or Build Your Own SDN?

An ESG survey shows a broad range of approaches among enterprises when it comes to deploying software-defined networking.

A couple of years ago, when software-defined networking was still in its infancy, I polled a half dozen or so network managers at enterprise locations to gauge their preference for consuming SDN technologies. Did they want to buy a complete SDN solution from a vendor or build their own?

Granted, it was very early, but most of these enterprises thought they would want to buy complete solutions from their network vendor. It was also very clear that the uber service providers such as Google and Yahoo, as well as universities, would rather build their own. That makes sense, if you consider one of the biggest distinctions is that those service providers and universities have skilled programming talent available to build SDN applications.

Fast forward to the present day. The SDN market, though still nascent, has matured a bit, and products are becoming generally available for proof-of-concept testing and pilots. The big question now: How has that mindset shifted? How do enterprises want to consume SDN solutions now? ESG recently surveyed 303 enterprise organizations in North America to find out. The results show a mixed environment.

To clarify, for the purposes of this discussion, a software-defined networking (SDN) solution would essentially be an application or service that is being delivered over an SDN-enabled network (could be physical or virtual) -- for example, load balancing, security (IDS/IPS, FW), and WAN optimization. These products or services could be developed by a vendor internally or in conjunction with partners. Many network and virtualization vendors have created an ecosystem of partners around their SDN products to develop a wide range of solutions and services. (There have been numerous ecosystem announcements lately; notable ones include those from VMware around NSX and Cisco around ACI).

The highest percentage of respondents (34%) indicated a preference to buy a complete SDN solution. Less than a quarter (21%) of the respondents replied that they would build SDN systems themselves, and almost a third (31%) said they would leverage a combination of buying and building SDN systems. In a separate question in the survey, organizations were asked to name the most important factor influencing their software-defined networking purchases. The top three responses were price, pre-qualified solutions, and breadth of solutions.

Figure 1:

This data showing a varied approach tracks with anecdotal evidence we have seen. Organizations, based on their capabilities and requirements, will decide what the best approach is for them based on the application or service. For example, at this year's Open Networking Summit, a panelist from a very large financial organization reported deploying a network TAP application leveraging SDN technologies that the company had built itself. Last year, a large school system revealed how an SDN-based security product from its network vendor (HP) helped it secure and more effectively manage its campus environment.

What should an organization consider when deciding whether to build or buy? What are the implications of choosing one path versus another? Some items to consider when buying a pre-certified solution (either single SKU or reference architecture) include:

  • It should help to accelerate the time to value.
  • It should provide a high degree of confidence that the product will work as advertised; look for either third-party validations or customer case studies for assurance.
  • It should have standard maintenance and support from the vendor(s).
  • If multiple vendors are involved, organizations should evaluate the strength of the partnership, as well as the cost of the solution, including maintenance. Make sure to understand how support will be structured.
  • Organizations should find out if there is any ability to customize/optimize the solution, if needed.
  • It may create vendor lock-in. Many of the available SDN technologies, though open, may limit an organization to a specific vendor. If selecting this path, be sure to understand the breadth of products available, both today and in the future. This would include evaluating the ecosystem of partners -- do they represent solutions already in use? Organizations should ask to see the roadmap and judge vendors on their ability to execute against it.

If you're building an SDN solution, here are some factors to weigh and questions to ask:

  • It should provide the ability to customize a solution for an organization's specific environment.
  • It should enable organizations to control the product roadmap and new functionality.
  • Depending on available resources, it may be more cost-effective.
  • It will require the organization to have skilled application developers available for IT solutions; this extends beyond initial development to maintenance and support.
  • Does the organization have skilled resources that understand the solution, i.e., security, load balancing, TAP aggregation, and WAN optimization? And do those resources have time to dedicate to creating this app?
  • There's the choice of underlying infrastructure: vendor specific or open standards-based?
  • Processes must be in place to document the SDN solution to alleviate issues if resources leave the company.

Ultimately, it will be up to each organization to decide how it will pursue SDN deployments. It also will be interesting to see how those decisions impact purchasing decisions for physical and virtual network infrastructure.


SDN decisions

Bob, thanks for this post -- there's a lot of great information packed in here, especially in the lists of what to consider. I'm intrigued that so many of your survey respondents said they were planning a combination of build and buy. Are there any additional gotchas in a combination solution that you haven't already mentioned?

SDN choices

Interesting to see in the ESG survey how few respondents said "too soon to tell" or "don't know" when asked whether they would buy or build. I would think many more would think it's too early to figure out how they'll tackle SDN, if they will at all.

If SDN is virtualization of Network Services then what does N...

It looks like ESG's definition of term SDN is completely different than what folks from ONS and ODL define SDN. None the less it is interesting article.


General SDN or purpose-driven?

If you ask people if they want to have a single vendor provide "networking" or if they will go with a hybrid, most people will tell you that they will go with multiple vendors. The term "network" is simply too broad to consider one vendor for all aspects. 

When ends up happening is that people build out specific parts of a network (datacenter switching, WAN aggregation, campus, whatever). And for each of those, they can make a set of decisions.

Talking about SDN in general does two things: it paints too big a picture, and it presumes that the thing being deployed is SDN. SDN is a tool. It is useful, but it is not the thing you deploy. You deploy network monitoring (Tap applications). That you use SDN is interesting (possibly even differentiating), but it is not the highest order thing.

What the suvey tells me is that people know SDN is coming but don't yet know enough about how to use it, else they wouldn't be talking about it as the thing. Collectively, we have to get past talking about the underlying tech and more about what that tech actually does.

Mike Bushong (@mbushong)


Re: General SDN or purpose-driven?

You make a good point Mike. It seems in general there's so much on focus on/debate about SDN technology that the actual business benefits get overlooked. Tom Hollingsworth wrote an interesting blog about this topic earlier this year:


Custom seems high

I was surprised that 21% said they would hire programmers to write custom code. That number seems high to me.

if companies buy sdn solutions, then network engineers..

if companies prefer to buy sdn solutions from vendors then what will be the job of network engineers of those companies, it means there's high chance of unemployment.