SD-WAN Q&A with Jacques Fourie

The Q&A

Today we’re focusing on SD-WAN, in particular around networking. We’ve heard the term SD-WAN used a lot recently in a lot of articles and in customer interaction. My first question to you is, what is SD-WAN and how does it differ from the type of networking we’re used to, such as MPLS or direct lines into data centers for connectivity?

I think we need to look at it in two ways. So first of all, it’s the way we deploy networks. So we’re looking at links into public cloud data centers like Azure. And when we’re coming into those type of platforms, we’re no longer coming into hardware based appliances, traditional firewalls and reaching infrastructures. If we go back down to the sites and the office layer, yes, we have these appliances, but the deployment is happening on the software layer. So it allows for speed of deployment as well.

Next, if we look at the landscape, people are consuming a lot more resources from SaaS based platforms like Office 365, and applications in the cloud. So a centralised network using traditional MPLS, VPLS, lease lines, becomes less effective because your resources are more web-based. So what we tend to do there is leverage standard internet connections using SD-WAN type of deployments to come back into the data center for the essential workloads.

I’ve heard of solutions such as VPLS. What’s the difference between VPLS and SD-WAN? Because I understand the VPLS solution is also using Internet lines.

VPLS would traditionally use a centralised network into data centers, consuming resources in central data centers. You might have a centralised edge there with the Internet hanging off the center of the data center, which is all good. But the thing is with that, there’s a lot of infrastructure behind that. It can become expensive when they’re global. And if you have to split those entry points into different vendors, they can become a nightmare to manage as well. If you try and centralise the vendor, not a lot of vendors provide global VPLS, and if they do, that can be expensive in some countries

I think decentralising the network and making use of Internet lines to provide WAN services over them – obviously secured with SD-WAN and a VPN type of encryption – basically brings a lot more flexibility to your WAN connectivity and then allows you to maximise the investment of your local circuit investment. So if you’ve got Internet on the site, you can use it for your WAN deployments to use stuff like the Microsoft Azure Virtual WAN, or SD-WAN deployments into other fabrics, but also still leverage that fast onsite Internet for various SaaS services that aren’t WAN related.

You’ve used the words ‘internet lines’ quite a bit there. With the recent increase in homeworking we’ve been hearing about breaches constantly. We heard about Solar Winds a few weeks ago and currently we’ve got Sonos who’ve been breached. Does using SD-WAN solutions make us less secure?

No, it doesn’t, because ultimately we use high-end encryption, like you would over VPNs to secure the WAN over Internet lines. Decentralising the network brings challenges, yes, it’s obviously easier to keep people secure if they are in one building on a LAN, it’s a lot more controlled, but that’s just not the way we work anymore. A lot of the software that we use is designed for mobility, is designed to work from home, and you want to give your staff the ability to work anywhere but work securely.

So when we talk about SD-WAN in branch office, we’re still able to secure it the same way we would be able to secure VPLS and those type of connections, if anything, we might have more control over those because we control the endpoints. From a security perspective, this brings us back to the core principles around the Microsoft stack, which is identity, endpoint, securing the device, securing the person’s identity and making sure that it doesn’t matter where they are – If they’re sitting behind a corporate firewall, if theyre sitting at home behind a home router, we are still able to leverage the same amount of security there on their device and secure the network.

Let’s look at it from a cost perspective. I think it’d be interesting to understand the difference between the cost of an MPLS style solution with the cost of the lines vs. SD-WAN with Internet lines…

If you take a traditional architecture, say there’s an office in the US, an office in Asia, an office in EMEA. You would maybe have some data centers, some workloads and then you would have to connect them all up on a VPLS to provide that low latency type of centralised network for people to be able to share and access resources. That could be quite costly because first of all, you need to either split your providers, which adds management overheads to match the requirements of each country. If you’re lucky enough to have a global provider VPLS, your management overheads are a bit lower, but still, the server costs are astronomically high and you’re still going to run into issues with localised deployments and management issues between the various different countries

So what SD-WAN brings is it just allows us to utilise simple Internet lines, from from good providers in those local areas. We then leverage the Microsoft Azure fabric, which is a 40 gigabit per second backbone. Rapid deployment using SDN type of appliances like Barracuda, to get fast deployment into the WAN fabric, and then you leverage Microsoft’s Global Network to provide that global connectivity to workloads that might exist in different countries for various compliance reasons for people to access. So the speed of deployment, the flexibility there is key to those type of deployments. SD-WAN allows us to to run those kind of virtual WAN services over Internet lines and not compromise on security.

So I guess for clients with an international requirement, taking the SD-WAN route would be a lot cheaper, because MPLS circuits are expensive on a global basis?

Yes, 100 percent. If you look at your circuit requirements, and you’ve got an SD-WAN fabric to back you up, your actual local circuit requirements become just Internet. And Internet locally in any country is a lot easier to get than VPLS into a into a global network fabric

So if we’re looking at a decent internet provider in each region and then using SD-WAN over the top of that to provide secure WAN services into workloads. Then leveraging backbone fabrics like the Azure virtual WAN to speed those deployments, and then that means low latency access from anywhere in the world onto a really cost effective WAN solution, just by having good Internet on the site and the right type of appliances on the site. So your deployment costs and your speed of deployment become a lot lower. And also the management overhead is a lot lower as well.

So moving on to management overhead. What are the key differences between managing a traditional MPLS or a bespoke type environment versus SD-WAN from a cost of management and monitoring perspective?

I think we need to look at the complexity of VPLS deployments. Unfortunately, with a lot of network deployments, there’s a lot of overengineering out there. But if we just keep it simple, you’ve got routers to manage the WAN portion of your of your network, so there’s circuits and provider level things to manage there, as well as any Internet portion of your network. So they’re not unified.

The second thing is, you know, they go down. You’ve got to have failover lines or VPNs, it can become quite messy to keep the uptime of the network as well. For a low deployment overhead SD-WAN really ticks the boxes because we use appliances from partners like Barracuda, like Fortinet, like Cisco to be able to stand up sites very quickly to the same security standards at the site. So that means that branch network can be stood up very fast and brought onto the SD-WAN and then managed centrally. So from a network engineer’s point of view, it’s a low touch deployment after that. Aside from your standard maintenance.