Cloud Application Acceleration

First, we had WanOp, then we had “son of WanOp” AKA SD-WAN (and its much misunderstood – mainly by vendors – sibling, SDN) and then the cloud came along and, well, clouded the scenario somewhat.

If WanOp was designed for classic hub and spoke type deployments, then SD-WAN was ye great “MPLS killer”, with added intelligence, multiple routing capabilities and the ability to optimise over any kind of connection, in theory at least. But it hasn’t killed MPLS. Does that mean it’s failed? Absolutely not; simply that it is only part of the answer. Given that, since its inception, SD-WAN has been attempting to resolve an ever-changing IT landscape, it could never be the only holy grail; we need an entire collection of them. In other words, SD-WAN fixes some problems but not all. For example, connecting cloud resources was not on the original SD-WAN agenda, so is not a natural extension of the technology, especially when extended to the mobile world. For a bang up to date take on SD-WAN, it’s probably worth taking a look at Forrester’s recent update on the market:

https://reprints2.forrester.com/#/assets/2/1933/RES157472/report

Note that, in looking at supporting cloud optimisation, it is as much about what SD-WAN isn’t, as what it is. And how we avoid clinging on to expensive MPLS circuits as part of the solution. IT “performance” problems inevitably fall into the “same old, same old” category and – with an increasing “new norm” reliance of real-time applications globally, the dreaded “L” words and its “PL” sidekick have risen back to the surface more than ever. Latency and its associated packet loss are the connectivity killers, way more than limited bandwidth availability can ever be. The longer the distance the data travels, the more likely – given the number of nodes it passes through – that latency becomes the primary obstacle. So, improving end-to-end throughput is a matter of managing latency and loss, not providing unlimited bandwidth. Which is why MPLS circuits are still in popular use, regardless of their expense, since the MPLS provides take the responsibility to deliver that data as latency-free as its SLA dictates.

As soon as you bring the public Internet into play, however, the latency and packet loss worlds change. Networks are not micro-managed in order to minimise impact; instead, it’s a free for all. And each element or segment of that network has difference performance characteristics, along with their associated limitations, not least the infamous “last mile” – between the edge sites and their local ISP networks – and the less understood “middle-mile” that connects the two last-miles. Traffic moves between these segments by rules based around providers’ mutual peering agreements, or whatever transit agreement they have in place. Over shorter distances, latency is less of an issue, but packet loss isn’t. In most cases, in order to be revenue positive for the provider, over-subscription of the last mile especially is commonplace; and as users contend for that limited capacity, it creates network congestion which causes – you guessed it – packet loss, which can massively impact the “me me me” applications needing that network availability to be as pure as…

Within the middle-mile, packet loss continues to be an issue, particularly at congested peering points, but it’s latency that’s most pronounced. Distances here are an issue, but equally, the economics of designing a network to make money for the provider means that economics, rather than app requirements, dictate how that traffic is routed, which is to say – often in a less than direct fashion. The result, despite SD-WANs best efforts, can be latency heaven (for latency that is). Which is why MPLS contracts are still often renewed; the guys at Cato Networks have a few thoughts on this, which are – again – worth a read:

https://www.catonetworks.com/blog/mpls-upgrade-for-the-modern-enterprise

And here is where the cloud comes into play; if SD-WAN alone cannot ultimately kill off MPLS, then a hybrid architecture approach – a cabinet full of holy grails – has to be the answer. Some call it SASE… By converging SD-WAN, a global private backbone – and here we have discussion for another blog day, do you take your SASE with or without one – a full network security stack, and support for cloud resources and mobile devices provides true end-to-end optimisation; at the last mile, through the middle mile and at the endpoints. It also makes end-to-end security readily manageable; one system, one console, a global network of happy users.

Here’s to 2021 being a better vintage than its predecessor…

SearchCIO
SearchSecurity
SearchNetworking
SearchDataCenter
SearchDataManagement
Close