It's been a while, but I general try to limit my posts to larger issues and trends, and this one is as disruptive as the threat to truck drivers by self-driving Tesla tractor-trailers.
Back in late 2009, I wrote that the Internet is rapidly becoming a viable mechanism for Enterprise communication needs. Eight years later, the growth of the Internet and Internet-based services have been more explosive than I every imagined. The introduction of the Apple iPhone in 2007 led to dramatic changes in the entire Internet landscape, putting what are now billions of connected devices all chattering on the Internet for information services of tremendous variety.
These uses are of course, not limited to entertainment and the occasional check of stock prices, but whether at home or mobile, billions of dollars of commerce are directly related to the the ability of the Internet to provide both high-capacity and highly-reliable services. Of course, the same companies that rely on the Internet for their customers, do not rely on the Internet for their internal mission communications. Microsoft, Amazon, Google, and other have their own nationwide and international fiber networks that form that backbone of their businesses.
So for most enterprises, what are the options on the on the continuum of the Internet to a private fiber networks. Until recently, an enterprise could build their network over the Internet (using IPSec tunnels, etc.) or over managed bandwidth services distinct from the Internet (e.g., common called MPLS/VPN services). Of course, there is the combined case, where both can be combined. For example, using Internet services (e.g., 4G wireless) as a backup in case the MPLS/VPN service is disrupted.
In both of these cases, a common denominator is the need to "build" the network out of network transport pieces provided by service providers. The build has led one of the major costs and limits of recent network technology. In general, we buy routers and then we need to buy the Router Jockey talent needed to create the configurations that make it all work. Not only are the Router Jockeys needed, but a set of network management software will also be needed to configuration manage, monitor, and trend the resulting network. Unfortunately, in many cases the Router Jockeys and Network Management Engineers are hardly on the same page. Engineers like to tinker, and with the hundreds of configuration options on routers - with solutions driven by "feel" - network services may suffer. Just try to figure out how to configure a network that uses a combination of MPLS/VPN, Internet, and 4G-Internet services to provide a robust network in the event of network failures. After the Router Jockey talks for 30 minutes about Equal-Cost-Routing and MPLS labeling, go for a drink and know that there is a better way (don't even start with how to set-up all the IPSec tunnels you are going to need).
Software Defined Networks (SDN) was the better way that was supposed to come to the rescue. An approach that moves towards central control and management of network elements, should have been the answer. But, again due to the complexity and lack of standardization, few enterprises have been able to take advantage of SDN.
So, how about a new approach one that looks at an enterprise network as a complete system. A solution in a box that understands end-to-end security, an ensemble of network devices that actually make a network, and does not care about the type of transport used to make the network. Add Web-based control and RESTful APIs to integrate into an enterprises management system and you have the emerging world of Software Defined Wide Area Networking (SD-WAN).
SD-WAN has all the goodies built in to make network configuration faster, moving away from the Router Jockey to just another IT person configuring a IT system. However, how does this address the issue of Internet services for Mission critical applications?
Tied directly into the SD-WAN approach is the addition of Packet Forward Error Correction (PFEC) technology and link bonding. Unable to be performed by a standard router that only knows how to forward packets, PFEC uses very similar approach to the FEC found on optical communications systems. PFEC sequences packets and adds additional overhead that enables in many cases the reconstruction packets dropped by the transport network (e.g., Internet) by the receiving SD-WAN device. These techniques have existed for some time in WAN acceleration devices - however sitting on top of a standard network routers. Finally, SD-WAN devices have combined PFEC and transport link bonding to use multiple transport services (e.g., MPLS/VPN, Internet, Satellite, 4G-based Internet) to provide amazingly robust end-to-end services.
Configured by a Web-page based on user needs and mission priorities, SD-WAN is going to continue the trend on what I wrote about in my early post driving Enterprises towards Internet-based transport and start a new trend - Router Jockeys are going to have to find a new link of work.
No comments:
Post a Comment