Sergey Nivens - Fotolia

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

Top SDN news and trends of 2014

In 2014, SDN trends were largely defined by the transition from theory to action as vendors productized the technology and engineers sought out SDN skills to prepare for change.

SDN analysts have a hard job. The technology has both boiled over with market buzz and yet remained at a simmer in actual uptake. To forecast in such an environment seems impossible.

As journalists, we don't forecast markets, but we can gauge where a technology stands by analyzing what our readers are searching for on our sites.

In looking at SearchSDN traffic numbers from 2014, we can glean a few solid SDN trends. Engineers are taking SDN investments and implementation seriously, seeking out more information and technology for proof-of-concept projects. Even further, on an anecdotal level, we've seen a rise in users who are willing to share their early SDN adoption stories. Those use cases have ranged from large enterprises implementing SDN WAN solutions to service providers using SDN and NFV to alter their core infrastructure.

As SDN investment and implementation grows, it only makes sense that engineers are seeking SDN skills through new certification programs and university programs. This year, the smallest story about a new SDN certification or specialty course drew scores of readers.

Analysts are also seeing these trends, and therefore their SDN forecasts are aiming high. This year IDC predicted the SDN market would expand to more than $8 billion by 2018 from $960 million in 2014.

From analyzing our own editorial content traffic numbers, here are some 2014 SDN trends we've noted.

Engineers are desperately seeking SDN skills

Considering 2013 was the year SDN became productized by mainstream vendors and startups alike, it only makes sense that 2014 became the year that network engineers began desperately seeking SDN training and certifications to prepare for a transition.

One of the highest traffic-ranking stories of the year was a piece documenting an Interop NYC panel in which experts warned network engineers that seeking SDN and network programming skills could be just as important (if not more important) than going the traditional Cisco Certified Internetwork Expert (CCIE) route.

Network engineers probably still need traditional certifications, but hardware vendors wasted no time building their own SDN certification courses and testing. VMware unveiled an NSX certification program they're referring to as "the new CCIE," and Cisco unveiled a series of specialty SDN courses with certification tests that are aimed at higher-level CCIE and Cisco Certified Networking Professional (CCNP) engineers.

Meanwhile, the Open Networking Foundation (ONF) began preparing the first vendor-neutral SDN certification program. Still the best bet for many engineers may be heading back to the college classroom. It turns out, quite a few universities are tackling SDN curriculum.

When will SDN investment become a reality? That depends

Engineers are a snarky bunch. Shocking statement, I know. But when it comes to talking about SDN investment, it’s like snark on crack. Everybody has a reason why we are nowhere close to SDN investment.

However, when poking into Google Analytics to determine the highest traffic stories of the year, what rose to the top was an interesting mix of engineers bitching about how SDN is too immature for investment, while also seeking pieces that helped them ask the right information to take their first steps in SDN investment.

Two high-ranking traffic stories of the year, included 42 SDN vendors to know (please don’t ask how we got exactly 42), and another that offered up 14 questions to ask SDN vendors before investing. (Again, not quite sure how we got exactly 14).

At the same time, contributing writer David Geer set out to ask engineers to describe the barriers to entry in SDN, and what he came up with was five solid reasons why network engineers are simply not ready to buy SDN. Geer also posed a question about SDN investment on Reddit, only to get a firestorm of reasons why users won’t invest in SDN.

So, which of these sentiments will hold true? Probably both. Resistance to an immature technology is to be expected. Yet companies who are facing real pain points that SDN may be able to cure will be forced to take the technology seriously.

The Cisco vs. VMware debate dominates, but does it matter?

Last year Cisco and VMware came to market with very different SDN and network virtualization strategies.

In 2014, network engineers began the Cisco vs. VMware debate, sizing up both strategies, implementing testing and revealing the benefits and challenges of both. Debate was stirred up when Cisco submitted the OpFlex southbound protocol to the IETF. Some saw it as a direct competitor to OVSDB, which manages across Open vSwitch implementations and is used by VMware.

Meanwhile, other engineers saw the Cisco vs. VMware debate not from a technical perspective, but from a cultural one. Blogger Teren Bryson explained that systems folks would simply be more comfortable with a VMware, software-only approach, while network folks want to put their hands on at least some hardware.

Some engineers went beyond their comfort levels and protocols to debate the openness of both strategies. Blogger Patrick Hubbard said Cisco has a chance of outrunning VMware simply because the ACI architecture is more open than anyone expected from the networking giant. Hubbard said the most unexpected development of Cisco’s ACI release was putting “coherent APIs” on the hardware, allowing for the use of a range of SDN controllers.

While it’s very likely the VMware vs. Cisco debate will continue, it’s kind of a shame to waste so much energy on just two companies. While the market yammered on about NSX vs. ACI, a number of other vendors from Nuage to Brocade, Dell, HP and Juniper, Midokura to Viptela and Cloudgenix, offered up SDN and virtualization strategies that should definitely not be overlooked and could ultimately kill the two-company debate.

Control issues: OpenStack, OpenDaylight, and where the two shall meet

In 2014, OpenDaylight Hydrogen was released and vendors began to incorporate OpenDaylight code into their products and services. Meanwhile, networking became a more central element in OpenStack orchestration and control, though engineers pointed out that OpenStack Neutron networking was fraught with problems.

Of course, considering that OpenDaylight focuses on SDN control while OpenStack Neutron is about cloud orchestration and automation, engineers began to question just how SDN control and orchestration differ from each other. Ultimately, there will likely be integration of OpenStack and OpenDaylight. However, there is a long road to determining which set of technologies will control various elements of network management and provisioning.

NFV brings a new kind of service provisioning

In 2013, most people had no idea what NFV was. Yet in 2014, it became one of the most commonly researched network virtualization topics on SearchSDN. That’s because NFV will be used by telecom service providers for service chaining -- or the ability to automatically provision network services in a matter of minutes rather than in weeks using virtual components.

While it’s possible to implement NFV without SDN, in many cases, service providers will combine SDN and NFV to simplify service chaining. As service providers seek answers for NFV, vendors have wasted no time in creating NFV infrastructure. At this point, there are so many vendors offering NFV products -- including those like Dell that don’t have a service provider legacy -- that it will be difficult for engineers to make choices. The good news is that early adopter service providers, such as AT&T with its Domain 2.0 initiative, will lead by example.

Bare-metal switches take hold

Network engineers may not be ready to end their relationship with feature-rich, proprietary network switches, but according to our traffic numbers, they're definitely interested in learning more about both bare-metal switches and white box switches.

With bare-metal switches, software is disaggregated from hardware, which means engineers can choose their own network OS. As more vendors make bare-metal switches available, a number of vendors are developing network OSes that can run on this hardware.

While initially engineers are likely to use bare-metal switches to replace simple top-of-rack (ToR) components, eventually they'll begin to deploy them more widely throughout their networks because bare-metal switches will be more open to Linux and DevOps tools, and therefore central to network automation.

This year, Facebook revealed an internally developed network OS along with a ToR bare-metal switch. The work came after the company's Open Compute project had set out to define specs for an open source network switch in 2013.

Facebook also provided a peek into its new Altoona data center network, which relies on open switches, a software fabric, centralized BGP control, and a massive, yet simple, orchestration system that defines network configuration.

In 2014, Dell also focused heavily on bare-metal switches. Specifically, Dell is offering a reference design to use Cumulus OS with either NSX or Midokura's MidoNet as a network virtualization overlay.

Let us know what you think about the story; email Rivka Gewirtz Little, or follow her on Twitter.

Next Steps

Top ten SDN news stories of 2013

The network manager 2015 wish list

What SDN engineers will really work on in 2015

Dig Deeper on Network hardware and SDN

PRO+

Content

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

Start the conversation

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.

-ADS BY GOOGLE

SearchNetworking

SearchEnterpriseWAN

SearchCloudProvider

SearchUnifiedCommunications

SearchSecurity

SearchDataCenter

Close