Building SD-WAN architecture into your world
A comprehensive collection of articles, videos and more, hand-picked by our editors
In recent online commentary, an analyst explained why he thinks SD-WAN could spell trouble for network functions virtualization. A blogger advised new engineers how to stay up to date with industry developments, without losing their minds. And a network software engineer defended open networking for all.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
SD-WAN could hurt NFV business case
Analyst Dean Bubley wrote on his blog, Disruptive Wireless, that software-defined WAN could ultimately undermine the NFV business case, by both decoupling enterprise applications from carrier network access and allowing noncarriers to make quality-of-service (QoS) promises.
One core tenet of a typical NFV business case: The technology will allow telecommunications carriers to deliver new virtual network functions at branch office locations, expanding their service portfolios and simplifying service chaining.
Bubley, however, said SD-WAN could short-circuit that model by placing a new layer of abstraction between telecom networks and enterprise applications. That, in turn, could restrict providers' ability to offer new, NFV-enabled services.
Further complicating the NFV business case, unified communications as a service companies can use SD-WAN technology to make QoS guarantees -- even though they don't themselves control network connectivity. Bubley called this model -- in which SD-WAN empowers noncarriers to make carrierlike QoS promises -- "quasi-QoS." As an example, he cited Vonage, which currently works with VeloCloud to improve QoS.
Check out all of Bubley's thoughts on the possible holes in the NFV business case.
Keep up with the SDN blogosphere
Fourteen software-defined networking blogs to follow today
Advice for new network engineers
Network architect and engineer Nick Buraglio recently tackled a topic that has likely troubled many networking pros in recent years: How to keep up with the barrage of industry developments, buzzwords and "must-know" technologies, without getting completely overwhelmed.
Buraglio said even he, a seasoned professional, has found the recent explosion in industry developments -- from SDN to containers -- daunting. He reassured green network engineers that they don't need to know everything; instead, they should aim to "know a little about most of it and a lot about one or two topics."
For example, while learning about code and network automation will undoubtedly help your career, Buraglio wrote, new engineers don't need to become experts in these areas overnight. Rather, they should understand the basic concepts and know where to learn more, if necessary.
In defense of open networking
Network software engineer Matt Oswalt said he thinks most of his peers too quickly dismiss open networking as just for the Googles and Facebooks of the world. In a post on his blog, Keeping It Classless, he wrote that open networking has a lot of unsung benefits that pertain to organizations of many sizes.
First, Oswalt argued that the commoditization of software benefits users, minimizing the need to reinvent the proverbial wheel when it comes to generating foundational code. Widely used -- and, therefore, widely tested -- open source software also connects organizations to a large community of fellow users.
Next, he added that open networking allows enterprises to adopt modularity -- beginning with a common foundation, mixing and matching applications on top of it. This results in greater flexibility and control, allowing users to switch vendors relatively painlessly.
Oswalt also argued that engineers should not view the data center as the sole purview of open networking. He predicted it will eventually make its way to the campus network, and maybe even the wide area network.
Read Oswalt's full thoughts here.
What to consider when building an NFV business case
SDN and NFV will work together in network infrastructure of tomorrow
The difference between NFV and VNFs