It’s not exactly news that enterprise businesses are moving workloads to the cloud; pretty much any analyst firm you poke will agree that cloud adoption will keep increasing in 2018, whether as IaaS (Infrastructure As A Service) or Saas (Software As A Service), and maybe even a little PaaS (Platform As A Service) . While the benefits and risks of the cloud itself are fairly well established at this point, enterprises are still struggling to adjust to the new demands being made of the WAN (Wide Area Network). This post examines some of the challenges introduced by IaaS and SaaS, and looks at ways to improve the user experience, both during service migration and after the workload is fully moved to the cloud.

A Bedtime Story

Once upon a time, things were relatively simple for enterprise IT. Business applications ran in one or more datacenters (often colocated with the head office), and remote sites were connected to these data centers over some form of private WAN, often in a hub and spoke design:

Full mesh connectivity for remote sites was reserved for those companies with more money than sense, a love of complex configurations, and a penchant for troubleshooting. When provider MPLS came along, it offered full mesh connectivity without having to configure all those nasty peer connections, and we all marveled at how we had ever done mesh networking without it:

Of course, Internet access was still centralized through the HQ site, because that’s where the firewalls were. Some sites also either couldn’t get, or couldn’t justify getting, an MPLS circuit installed, and those sites might be given an internet connection instead, and connect to the corporate network using IPSec tunnels:

+VPN-connected sites may have gained some full mesh capabilities from technologies like Cisco’s DMVPN, but were still effectively isolated from the MPLS. What should be obvious is that despite the advances in the underlying technologies, a typical enterprise network still focused on the data center being the center of the network (because that’s where the business workloads ran), and rather than having to configure a firewall at every remote site, policies (and firewalls) would be implemented centrally.

So what changed? Moving to the cloud kind of messed things up in the happy world of the network admin. Suddenly the workloads moved from being in one place (the data center) to being distributed around the internet:

Looking at it, this particular bedtime story might trigger nightmares rather than sweet dreams.

The “aaS” Monster Under The Bed

The use of IaaS/SaaS has dramatically changed WAN usage. because traffic which once stayed within the enterprise is now going out to the internet. Worse, it could be going almost anywhere on the internet, geographically speaking. Anybody with a centralized network like the ones pictured above has probably either already experienced problems, or has already realized that a sudden increase in Internet traffic through a single choke point in the HQ/Data Center is not going to scale well.

SaaS applications create another problem, which is how to prioritize traffic for those key applications. Once a critical business system moves out of the data center where it had a fixed IP address and instead now appears behind a variety of IP addresses on the internet, writing QoS policies becomes significantly more challenging. To add insult to injury, SaaS web traffic is almost universally transported in SSL, so it’s difficult to inspect the application within and identify the traffic on the fly.

SD-WAN Monster Spray?

SD-WAN (Software Defined WAN) is fairly well known now as a technology which aims to simplify the WAN, allowing centralized configuration and policy control which is then pushed out to edge devices at each site automatically, so that, for example, creating a full mesh of site-to-site tunnels is done automatically. Better still, each site can utilize multiple access technologies and SD-WAN can select the best one to meet the needs of each class of traffic as defined in the business policies. A good SD-WAN overlay network can do great things for network performance and reliability between offices and data centers in an enterprise.

Unfortunately, in an enterprise is the key phrase. As corporate connectivity is improving because of SD-WAN technologies, the adoption of SaaS is busily moving the workloads out of the enterprise network and away from that optimized WAN. If only the cloud could be part of the smart SD-WAN overlay network.

Sweet Dreams Are Made Of This

Good news; the IaaS cloud can become part of an enterprise SD-WAN! Running a product like Viptela’s vEdge Cloud Router can allow enterprises to connect IaaS clouds to the enterprise SD-WAN as if the cloud was just another site on the network. Bringing the IaaS cloud into the enterprise network has some obvious benefits, not the least of which is that the performance and reliability gained in the enterprise network can now be extended all the way to the cloud. The enterprise also gains visibility of network conditions to and from the cloud, and since the meshing is automatic as part of the SD-WAN, this is a far more scalable solution than trying to manually create multiple IPSec tunnels from each internet egress point.

There’s one more benefit to extending the SD-WAN fabric into the IaaS cloud. The SD-WAN fabric can already ensure that certain traffic stays separated from other traffic (a little bit like having multiple parallel vlans in the WAN), but now that isolation can be extended all the way into the cloud.

For IaaS services like AWS and Azure, it’s straightforward enough to spin up a VM which will act as a cloud router for SD-WAN, extending the fabric right into the provider’s network. For SaaS offerings like Microsoft’s Office 365, on the other hand, it’s a little trickier because users aren’t given access to run their own resources in Microsoft’s O365 data centers. To work around this, the SD-WAN’s designated internet edge gateways can monitor the performance and availability of the key business SaaS applications from their perspective. That data can then be used to determine which internet gateway will provide the best performance for access to the SaaS application, whether that’s by using the SD-WAN overlay to send traffic via a centralized corporate Internet egress point, sending it through the overlay to a dedicated Internet egress node (or any site designated to act as an internet egress point), or breaking out locally and tunneling directly to the SaaS provider from the remote site:

Choosing between the four paths above looks complex, and so it is. It simply isn’t possible to route the SaaS traffic intelligently using legacy routing protocols, even assuming that the SaaS traffic could be correctly identified for use in implementing that routing. This is really where software defined WAN comes into its own, providing better performance to key applications even when those applications may change location without notice and are running outside the corporate network.

Conclusions

Routing to the cloud – both for IaaS and SaaS – is difficult. Companies moving workloads to the cloud need to think ahead about how traffic patterns will change as a result, and mostly likely should be considering the use of an SD-WAN product which allows for a distributed security policy and optimized access to the cloud.

For IaaS, extending the SD-WAN fabric to the cloud means extending both the network and the security policies implemented on the edge devices, without the configuration scaling issues that go with doing so manually.

For SaaS, knowing the best way to get to a critical business app and merging that knowledge with the existing intelligence of the SD-WAN gateways means better and more reliable access to the apps that are core to the business. The argument to do so is compelling to say the least.