Veering Off the OregWAN Trail

Ah, the memories...

Industries prone to acquisition and expansion are starting to outpace traditional methods of WAN deployment such as the hub and spoke model—but restructuring your extended network is a massive undertaking, and it's all too easy to err on the side of what will serve you best right now (instead of five years from now).

Of course, if you look at the public cloud adoption rate (a projected 50% in 2018) and data growth rate of 20-25% per year, you'll see why a lot of IT leaders are beginning to reevaluate their network designs in order to keep up. Here's a simple explanation of why (and how) businesses will continue to shift over the next few years.

What Is A Hub and Spoke Network?

"Hub and spoke" (also called a "wagon wheel" network) refers to the traditional method of setting up a wide area network (WAN) over a virtual private network (VPN).

As the name implies, one site—let's say, the Kansas River—operates as the hub, or central site. Further down the Oregon Trail you'd have Chimney Rock, Fort Laramie, and the end of the line at Willamette Valley. (Yes, I've committed to this analogy.) Each of these spots would all connect to the Kansas River through their own individual VPN links, creating three "spokes" on the wheel. Each of those remote branches would need to communicate through the Kansas River in order to reach any of the others.

Pros of Hub and Spoke:

• Cheap and simple to implement: they only require one VPN connection between each new remote site and the hub (note that international links are more expensive so this might not always be the case)
• Easy to manage: your main concern is always that central hub, which makes it easy to prioritize network admins

Cons of Hub and Spoke:

• Single point of failure: if the hub site dies or experiences a connectivity problem, all the sites will lose connectivity as well
• Lots of network latency: because all traffic needs to travel through the same choke point, remote cloud-based workflows end up with a lot more lag
• Not good for easy collaboration between sites, and can't support branch access to multiple data centers

What Is Full Mesh or Hybrid WAN?

At the opposite end of the spectrum, the "full mesh" VPN model connects every site to every other site. Every stop along the Oregon Trail could communicate directly with every other stop, without any particular hierarchy between them. Mesh networks self-configure and organize in order to keep things running smoothly and balance workloads as they route data between sites.

Many organizations use a hybrid form of both hub and spoke and mesh network models. In a hybrid WAN architecture (also known as an "any-to-some" topology), the Kansas River, Fort Laramie, and Willamette Valley might all be able to communicate freely, while some of those middle points along the road would only keep a direct link back to the starting point.

Pros of Mesh/Hybrid WAN:

• Very reliable: because there is no single hub, a problem with one site won't affect the others (in a hybrid WAN model some additional sites might take the hit, but you'll still be able to handle far greater traffic rates than a hub and spoke model)
• Less network latency: sites can communicate directly with each other and the Internet instead of processing every piece of information through the central hub, reducing lag for cloud-based workflows
• Highly scalable: these models can handle a large amount of network traffic thanks to their automatic workload balancing
• Great for collaborative workflows and open communication

Cons of Mesh/Hybrid WAN:

• Expensive to set up: you need to invest in a lot of technology up front in order to connect every remote site with a mesh VPN deployment; even a hybrid WAN network will take a fair bit of capitol right off the bat
• Complex to maintain: such a large and complicated deployment requires either skilled administration or constant, machine learning-backed monitoring

What Are the Challenges of Network Modernization?

The Oregon Trail analogy makes it pretty clear why a hub and spoke model worked when the world operated within a fairly linear system of centralized data centers and one-off remote branches. But now that we live in an increasinly cloud-based and Internet-reliant digital ecosystem, that kind of strictly hierarchical architecture will only result in more and more costly lag for your organization.

If you're not ready to commit to the planning time and implementation costs of a full mesh network, upgrading to a hybrid WAN model will save you both the complexity of mesh and the crippling latency of hub and spoke.

Of course, while any-to-some topologies do enable smoother application delivery, they don't solve the basic problem of cloud adoption (a problem which even those who are happy with their hub and spoke models need to address): lack of control over your enterprise.

If your cloud traffic routes directly to the cloud but your legacy apps go through the central data center, you'll only have half the visibility you need to fix performance issues, maintain security, and optimize workloads to support modern bandwidth requirements.

So however your organization chooses to solve their remote site latency problems, you'll still need something very few IT and security teams have right now: comprehensive internal (east-west) visibility, meaning visibility into the one thing that all of these networks have in common. Which is to say... the network itself.

I'd be remiss if I didn't mention here that ExtraHop analyzes all network traffic at up to 100 Gbps, giving you complete and real-time visibility into every system, application, and device in use across every branch location as well as in the cloud. Visit our Remote Site Monitoring page to learn more!