SDWAN- What is it? What is it NOT?

Before I get into what I want to project, I will say that I have been in industry for around 35 years. I have “seen and done it all”. IBM standards like RJE, NRJE, APPN (for IBM transport), DLSW, etc. . Pre-Ethernet standards (ATT StarLan, ARCNet, Token Ring, FDDI, etc. ). We had X.25, Frame Relay, Serial WAN. We had OS platforms like 3Com (3+Open), Microsoft LAN Manager, Novell, Banyan Vines, XNS, DECNet, Appletalk, OSI, early TCP/IP, and the list goes on. Non-standard, ( a per-protocol rodeo). All worked well, but were self-contained. And we used routers, at that time, to provide inter-communications between all of these pre-standards. But, each protocol had a “standard” so we could reliably pass info between the environments with an arbitrator (router).

We have gone through a long period of time where we consolidated into industry standards to eliminate the pre-standards confusion. That is a good thing. This allows the consumer to pick the best solution (based on capabilities and scale) for their needs. It allows companies to focus their development investments to the real goal: providing differentiation within a common paradigm. That is why we have standards. Here we are again.

With the advent of “SDWAN”, that standards based foundation has fallen away. SDWAN is a concept, not a standard. Pick your own definition, and then say you "have it". We, in the market, have no less than 60 entities touting “SDWAN”. We have BIG $$ being spent from analysts publishing articles about "it". What is "It"? As a supplier, we always compete against “cost” as the def-facto standard. If there is no standard, what does a “car” or “boat” cost? What kind of boat, or car? They all run, and they all float. Lot’s of definitions. Depends on the use case. What is “YOUR” use case? What are “YOUR” requirements? Cost is not a good litmus test. But it is the de-facto question when all other levels of understanding fall away.

Bear with me based on all of the above. I can tell you that, based on time-over-target, that successful implementations are based on the right requirements: Business continuance and FAILSAFE (not failover) 100% uptime for mission critical applications like voice, interactive video, and VDI. Even in challenging scenarios like E911, aircraft, ocean-liners, drill rigs, etc., where bandwidth choices are limited. Speaking for us, we have a litany of customers who have “gone through the 60”, and have chosen our solution.

Our unique IP (patented) rarely loses to the other 59 (all things being equal).

So , what is SDWAN, and what is it NOT?

NOT-

-      An adjunct to your firewall?- No- SDWAN should indeed fold into your security equation. But, if your definition of SDWAN is a recent add-on from your firewall supplier, have your antennas up. Solution was was not originally designed to handle this type of load. You may be wasting your money, IMO. As an add-on, ask about ROI. You should test capabilities.

-      An adjunct to your Wan-Opt installation? No, or you need to validate- could be vendor self-preservation? Same as above. You should evaluate and test capabilities.

-      An add-on license to your installed router base? No- could be vendor self-preservation. Trying to work around their own, existing deficiencies. Again, what is your definition of SDWAN, vs. theirs ? You should evaluate and test capabilities.

IS- 

My definition of what SDWAN should be:

-      Fail-Safe, as opposed to traditional failover. Real-Time protocol resiliency. 911 level call level resiliency. No dropped calls, or sessions, even under adverse conditions. Consistent Interactive video quality, crisp VDI reliability, etc.

-      Bandwidth Agnostic- If you are paying for it, the solution utilizes it- All active, all of the time, and measured for real-time quality- MPLS, BB, LTE, VSAT, LOS, etc. If you are paying for it, the solution will use it, in real-time. Many companies are looking to migrate from MPLS, as an example. The solution should use all available bandwidth while it is available, and provide a transition path to alternate sources, non-disruptively.

-      Physical, virtual, and cloud-based deployment options- mixed, does not matter. Scalable, and manageable in a granular fashion.

-      Supports branch office CPE consolidation- Branch office routing, Firewall, Wan-Opt., when needed, via native capabilities, as well as integration with other, existing CPE entities.

-      Overlay (with fail-to-wire), one-armed or as an in-line deployment. Non- disruptive, low touch deployment. Do no harm- only enhance the legacy network.

-      HA options available for both data center and branch, across the board.

-      Supports distributed, centralized and cloud-based network security architectures- mix and match to fit your needs. Hub and spoke, partial mesh, full mesh options.

-      Consumable as OpEx or CapEx. DIY, or Managed by a 3rd party. Not tied to a specific service provider.

-      Discrete analytics and reporting- troubleshooting, SLA forensics, trending, capacity planning, etc.

If looking at SDWAN (and most companies are), please keep your eyes open and look at your requirements as opposed to cost (no context available-per above). SDWAN is not a standard. It is a rare, over-glamorized concept in this day and age. Keep your eyes open, and antennas up....