Bandwidth is not Free
What cost $675 in 2000, $5 in 2010 and $0.5 today? (1)
Answer: each Mbps of Internet transit in the US. An average of 35% discount every year
What was about 3.67 in 2007, 6.4 in 2012, 18.75 in 2017 (2)
Answer: average Internet connection speed, in Mbps, in the US: Average 20% growth every year
While the math seems to be moving ever in our favor, bandwidth is not free. In fact, looking at Internet transit only paints half of the picture. Many enterprises spend thousands or millions of dollars in private connectivity, in many cases, to transport packets bound to the internet.
Bandwidth, for the purposes of this discussion, is a commodity for which enterprises are growing in consumption year after year. It is not the type of service we try to cap like electricity. Either because we want to, or we have to, our bandwidth requirements are only going to grow. That being the case, we need to be smart about how to allocate budget to that item, to keep us competitive. Direct path to the Internet, particularly for users outside our enterprise network, is a must, but more on that later.
Let’s ask ourselves the following questions:
Should I pay for bandwidth to backhaul remote users traffic for security?
It is still a common practice to force roaming and remote users to tunnel all their internet bound traffic via IPSec or SSL VPNs. The assumption is still that we have to inspect the traffic and that the appliance-based security mechanisms are somehow more effective to alternative options. I will challenge that assumption, as these days, cloud-based security platforms are equally effective, exponentially more scalable, and several times more effective in staying updated with current threats, compared to customer premise appliances.
Should I pay for bandwidth to backhaul traffic bound for SaaS applications?
On a similar note, we force users to VPN before accessing SaaS. Arguably, such services have embedded security mechanisms that make any appliance-based solutions irrelevant. If you agree with me, you then need to look into the life of the packet that is SaaS bound: through the VPN into my hub, out to the internet to reach the destination, back into my hub, out to the VPN back to the user. For each 1Mbps of full-duplex traffic, you just paid 2Mbps of Internet transit (3Mbps if you let your users expense their home internet connections). WHY are we doing this?
Should I pay for bandwidth to backhaul traffic for IaaS access (Amazon Web Services, Microsoft Azure, Google Cloud Platform)?
At this point, we should realize that the VPN links that we may still need are merely to connect point A (users) to point B (applications). That being the case, does it make sense to deploy VPN services in every virtual datacenter? does it make sense to rely on our legacy VPN concentrators within our network to then turn around and reach Amazon Web Services over the internet (remember the point of unnecessarily paying for 3Mbps worth of internet bandwidth?). It only make sense to explore modern connectivity options like Software Defined Perimeter to gain in both efficiencies of communication, removal of capital expenses, as well as limiting the exposure of our private applications to the Internet and potentially to bad actors.
Should I pay for bandwidth to backhaul traffic for Internet access across a WAN infrastructure?
For the last two decades, we have been transiting regional and global networks in order to secure Internet connections. The cost of deploying security appliances at every branch office was too high both in terms of capex and opex. Today, those costs are still high, and pressure to do more with less continues to grow.
To that end, the natural step is to move those controls, much like we have moved our applications, to the Internet. On the path between the source (users) and the destination (the cloud), instead of funneling traffic through regional hubs. This scenario is not about unnecessarily paying for 3Mbps of Internet transit, but an additional $39 (3) per Mbps for Internet bound packets. That is the additional cost of transporting an IP packet through MPLS for the sole purpose to inspect it by hub-located appliances.
Now, Let’s talk Quality of Service. I spent many hours in the lab testing QoS mechanisms from every single networking vendor out there. It is arguably an effective way to prioritize business traffic. Having said that, as we move users and applications to the Internet, more and more of those techniques become ineffective as your routers are in the wrong side of the bottleneck.
If all possible you want to perform queueing and prioritization in the cloud, before the return traffic hits your ISP or your last mile. This is not only going to provide better experience when in-network, but will delay the need to upgrade links, provided that non-business traffic is the class that potentially faces starvation.
I believe 2018 will be the year where Networking and Security embrace the cloud much as applications have done in the past 5 years. Transforming enterprise networks and security stacks will both prove to be cost effective, and will enhance quality of experience. Direct to the cloud security platforms can deliver cost savings and provide a significantly better quality of experience to your users.