Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Buy Or Build Your Own SDN?

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.