Fast, Good or Low Cost: Pick Two or Get All of the Above?

In an environment where bandwidth requirements increase more quickly than some ISPs can deliver, what is the solution? My manager was known to tell the requestor this, “You can have it fast, good or cheap, pick any two.” In many instances that was true. We could get a “good” 10mbits/sec MPLS circuit, but it was going to be costly or delivered over a long period, or you could get a “good” low bandwidth 1.5mbits/sec MPLS circuit faster and for less money. This was often the case with a facility located away from major infrastructure. While this 1.5mbits/sec incremental bandwidth help our issues, it was not enough to keep up with the growing traffic and budget demands that we were facing.

Our first attempt to resolve the issue of “more please” was by installing an Internet circuit locally to avoid backhauling inexpensive browser traffic across an expensive MPLS link. That worked for a time, but we could already see new applications coming online trending the data usage higher. We also used the Internet as a VPN backup to our MPLS for redundancy with great success. Sometimes it was so resilient that the local staff would turn Telco service techs away when issues came up because they thought the circuits were all up and nothing was down.

The next iteration was WAN optimization. The industry leaders made their pitches and we created a short list for a proof of concept. The first one we selected was easy to setup and delivered such a successful demo that we bought the solutions and a few dozen more units without ever trying the second vendor’s much more expensive and complex offering.

That gained us more breathing room but in short order, an IP telephony rollout found issues in our WAN and QoS had to be tuned extensively to carve out the required queues to keep everyone mostly happy. QoS is enforced unfairness, so the bulk transfer guys complained from time to time but you can only do so much with a fixed amount of capacity.

At this point, we resigned ourselves to purchasing more bandwidth and the increase it would add to our operating expenses though we did keep looking for the magic box that would solve our problems. The MPLS network had become so saturated at a few locations and the Internet was often four to 10 times faster than the MPLS, so we had turned to the VPN as the primary circuit and left the MPLS to service as the redundant link. It worked but it wasn’t optimal and QoS suffered.

Then, one of our vendors met with us and, after hearing about our troubles with the ability to deploy sufficient bandwidth at many of our remotes, offered up Talari Networks as a solution. I had never heard of Talari, but the story was compelling though the claims seemed, as had often been the case many times before, too good to be true.

We started a proof of concept to investigate the Talari solution. It was simple to install (faster) and worked so much better than we could have imagined by allowing us to leverage Internet links and maintain application SLA’s (good) that we ordered several more at the end of the PoC. The Talari solution is less expensive (low cost) than the alternative of adding more MPLS bandwidth, so we were able to limit our financial exposure and secure a good ROI.

This was our sought after solution to the faster, good, low-cost conundrum. With each update, more function and improvement is added and we continue to see Talari as adding more value than we thought possible!

Categories: Software Defined WAN (SD-WAN)