Paid Content This paid content was written and produced by RV Studios of Red Ventures' marketing unit in collaboration with the sponsor and is not part of ZDNet's Editorial Content.

Is SD-WAN the messiah, or just a very naughty boy?

Is the new kid on the block - currently enjoying life at the "peak of inflated expectations" - about to dive into the "trough of disillusionment?" I think it could be...

Software Defined Wide Area Network (SD-WAN) is the single hottest technology trend in the data networking market right now - but do the key benefits really stack up?

In my previous "Superheroes" blog, I discussed how the Symphony initiative is using SDN/NFV to bring new agile offerings to the market, such as Telstra Internet VPN.

After reading my blog you may have assumed I jumped on the SD-WAN wagon, but I'm a little skeptical about this trend.

Right now, I'm excited by the use of SDN/NFV to develop automated/agile "as a service" network offerings but my enthusiasm wanes when it comes to the complexity of overlay tunneling to appliances at both branch and data centres - all for the sake of what exactly?

I do see these as different scenarios with the on-demand/agile deployment of something like Akamai Connect onto a Cisco router, connected to a MPLS network, delivering significant application performance benefits without an overlay tunnel in sight.

In my "Internet for WAN" blog I questioned the validity of any new model citing savings on WAN transport OPEX as a key benefit. I have seen a few of these propositions before and sense our customers are also starting to question whether SD-WAN is the new evolution of data wide area networking, or just a new way to sell a stack of intelligent (read complex) CPE.

In trawling through the latest web materials I enjoyed a recent TechTarget e-guide authored by analysts for whom I have great respect. I was impressed by their assessment - which echoes questions I have been asked by our customers around SD-WAN.

The guide - a largely positive, albeit cautionary, piece on SD-WAN- reveals snippets of why I think SD-WAN could be the latest "very naughty boy" on the networking block.

I am happy to be accused of bias - working for a network service provider and all - but the opening line in the guide seems in itself something of a red flag "vendors have cashed in on the popularity of software-defined WANs (SD-WANs)". Let's move on however, and discuss some of the benefits of SD-WAN referenced in the paper:

Increase security

In terms of increasing security, SD-WAN models overlay tunnels on the Internet to deliver secure paths but also necessitate, particularly where local Internet hop-off is implemented to get supposedly shortest hop access to cloud based SaaS, distribution of security policies to the branch appliance. Is the complexity worth the path shortening? Is the path really shorter?

Path concerns aside, I understand automation - as discussed by this fine looking rooster, will go a long way in terms of making the distribution of security controls easier. But back to the benefit statement, is security actually increased by SD-WAN?

Access public cloud services

One of the strongest growth markets right now is private side connectivity to platforms such as AWS, Azure as well as SP cloud platforms. Customers are favouring, due to reliability, security and application performance concerns, to connect direct from the enterprise private IP network, via for example a cloud gateway, to these cloud services. Noteworthy here, a recent favouring of Internet connectivity by Microsoft to Office 365, but our internal pipeline reveals strong private-side access market demand.

Improve application performance

I wonder - as tunnels are created all over the place - how many inefficient "hubs" will be implemented, adding traffic path latency. We have deployed our MPLS Provider Edge (PE) devices to more than 150 locations across Australia to optimise customer traffic performance - particularly in support of UC applications, and now as an alternate, the proposal is to tunnel traffic back via hub appliances. Yes, I know about dynamic site-to-site tunnels, but I question whether ISPs the world over have taken optimisation of path latency into account when deploying edge routing devices to the extent Tier 1 MPLS providers have.

Reduce cost

Have you reduced WAN OPEX but have not replaced it with appliance CAPEX and network management OPEX?

I agree with the guide's POC recommendation on SD-WAN (we are supporting quite a few via our Advanced Technology Practices team) as yes, you would really want to ensure your applications do work better - or at least as well as they do today - to justify the transformation you are about to embark on.

My questions aside - assuming you are convinced of the benefits of SD-WAN - the guide moves on to discuss infrastructure placement and three deployment options.

I plan to discuss these further in my next blog - in particular the in-network "as a service" deployment model, for which I hold passionate views. Yes, I understand the SP "lock-in" concern, but I also note the high degree of proprietary "special sauce" in CPE-based solutions today.

In closing, Gartner asserts technology hype needs to hit the "peak of inflated expectations" and then negotiate the tricky "trough of disillusionment", to ultimately reach the "plateau of productivity".

Many would argue SD-WAN has made it already, with Telstra already launching Cisco iWAN globally.

Considering this - and general SD-WAN market interest - I am not on the bandwagon yet, but maybe the market is.