Finally, even those who wrote all their own enterprise software, began using cloud compute and storage to develop on. Ease-of-use, low cost of entry, and low maintenance requirements have allowed cloud computing to invade nearly every aspect of our enterprise datacenter environments
This evolution has also transformed the way many of us view our enterprise WAN. With all of our applications in the Cloud, many of us ask ourselves if we really need those dedicated circuits between branch offices anymore. The trend is to look at inexpensive, Learn about the latest WAN products via our workshop.commodity Internet connections, and then just build IPSEC tunnels from branch to branch for corporate internal connectivity. Certainly, one might ask themselves, “Won’t we save money on the cost of the circuits?” The answer may not be so simple. At least not yet.
While many cloud applications today are being constantly tuned for tolerance against latency, jitter, and loss, the reality is that most of us still have some real-time applications in use inside our enterprise. Perhaps it’s your voice traffic, it may be videoconferencing, and it may be industrial controls or sensors.
We are surrounded by applications that are sensitive to latency, jitter, and packet loss. These applications require solutions that are predictable, dependable, and backed by a service-level agreement in the event of a failure.
The Internet we depend on today has become so ubiquitous, we almost don’t even notice it surrounding us in our everyday lives. However, from a network engineer’s perspective, the Internet is often something less than predictable, dependable, and stable. When I challenge the stability of the Internet, I’m not talking so much about the availability of it, but as network engineers we know that the path I’m taking to Amazon’s AWS servers today, may not be the same path I’m taking to them tomorrow.
Similarly, the path I take (using the Internet) from one branch office to the other changes over time. These changes also mean changes in the latency, jitter, and delay of that connection. The path you’re taking over the Internet (or any network) determines your end-to-end latency to a large extent. Congested links, busy routers, routing changes, and even disputes between providers can mean that your latency over those links will change from week to week. A situation called asymmetric routing can also mean that the path you take from Branch A to Branch B, is NOT the path you take from B back to A.
Asymmetric routing, in and of itself, is not harmful, indeed it’s actually pretty normal on the Internet. However, if the two paths have very different latency/jitter profiles, this can wreak havoc on the performance of your real-time applications like voice and video. On a commodity Internet connection, there is also no way to guarantee the delivery of every packet. Indeed, even the delivery of MOST packets is not guaranteed. All of this means that trying to define the “normal and expected” performance of the Internet can be as difficult as to trying to weld a snowball to a plate glass window. If you have real-time applications that don’t tolerate this sort of unpredictability very well, Global MPLS solutions may be your answer. MPLS solutions are built on predictable, managed circuits.
Even when coordinated between multiple providers around the country or around the globe, the path you take from one branch office to another in an MPLS environment will change very little, or not at all from year to year. These services are provisioned for the use of one customer, and the bandwidth can be guaranteed day in and day out. Because of this, the latency, loss, and jitter profiles on these circuits are predictable, dependable, and stable. These Global MPLS services are generally backed by a service-level agreement (SLA) that allows you, the customer, to choose levels of downtime, packet delivery, and class-of-service guarantees that you’re comfortable with. As an enterprise, the SLA gives you the ability to nail down an exact framework for the definition of the “normal and expected” performance of the network.
If your enterprise needs the reliability of an MPLS solution, but you want to take advantage of commodity Internet circuits for “backup” connectivity, there are hybrid solutions available. Newer technologies like SD WAN allow you to blend the technologies. You can have a Global MPLS solution between branches that serves as your primary connectivity. Your SD WAN solution can be configured to only use the commodity Internet connection as a backup. Alternately, if you prefer, you can utilize the commodity connection for users’ Internet connectivity and only send corporate traffic over the MPLS connections. There are a number of things you should consider before deciding between commodity Internet connections or something more dedicated like a Global MPLS solution.
You need to search out and identify your real-time application needs. You need to profile those applications and determine what their exact needs are in terms of latency, loss, and jitter between branch offices. You should talk to your users and find out just how often their calls are dropping today, or how their latency sensitive applications (like long distance file sharing) are working for them. Do your best to assess the cost of these applications to your enterprise. How much money is lost when a call is dropped?
How much time and productivity is lost if the time to transfer a file goes from thirty seconds to three minutes, and then is amplified by multiple users across multiple branches. If you do decide that you need a Global MPLS solution (with or without SD WAN), you need to consider a few more things. Can this provider get me to all (or almost all) of my locations so that I can keep my billing and support calls all with one vendor? How does their service-level agreement compare to the competition? What is their reputation in the industry? And of course, the almighty, can we afford them?
Cloud computing has no doubt changed our landscape, but dedicated services like Global MPLS are here to stay, and if you wisely blend them with commodity Internet connections, and SD WAN deployments, you can have the best of both worlds. You can use less expensive commodity Internet connections for your backup circuits where you need two connections for redundancy. Or, you can reduce your MPLS bandwidth buy, and use the commodity connections for the bulk of your branch user’s connectivity, reserving the MPLS circuits for the truly time-sensitive internal traffic. No matter how you choose to blend these services, they’ll all be a piece of our landscape for a long time to come.