Skip to main content Skip to search
Carl Levine
Posted by
Carl Levine on
July 11, 2018

Addressing the Middle of the Country Routing Problem

Conventional wisdom would suggest than an internet user in the middle of the United States, attempting to access a resource hosted in two different locations, would have an equal shot of reaching either one of those resources. Application performance pros have been touting the power of georouting for years, and would argue that the physical distance of that user to the datacenter or cloud availability zone would predicate the decision that a DNS resolver would receive when querying for an endpoint. 

The truth of the matter is that the closest endpoint from a geographic standpoint is not always the most performant, or even the one that is available at that point in time. Complacency with the georouting paradigm has allowed this "Middle of the Country" problem to exist, and there is a better way to serve the businesses and internet users who aren't close to the coasts, where the lion's share of the cloud availability zones and datacenters primarily exist. At NS1, we have the data that solidifies this statement and we're going to explore this specific challenge now.

The Challenge

It’s a golden age for an enterprise that is looking to shift capital expenditure away from buying and maintaining physical, on-premise servers to handle their workloads, and reap the benefits of leveraging the cloud. There is a diminishing rate of return on the economics of operating a private network, with private connectivity and dedicated on-premise servers these days, and that is directly attributable to the shared economies of scale commensurate with the advent of cloud computing.

This presents a trade-off, however: performance of a dedicated environment vs. leveraging the public internet to connect these critical systems. Yes, even in 2018 when the internet shares a level of ubiquity on par with any other utility, the physical location of services must be considered carefully. For a company based in the middle of the United States, connectivity to resources physically located at either coast is available, albeit with added complexity of establishing the most efficient route to traverse networks and make the connection.

Challenge: Giving the middle of the country the fastest route to resources on either coast.

Leveraging Real-User Monitoring To Enhance Performance

At the core of all internet applications and resources we have the Domain Name System, DNS. Despite the DNS’ critical place as the first stop in all internet or application infrastructure, many organizations still use legacy DNS solutions built on an outdated, 30-year-old technology that can’t handle constantly changing user, traffic and application conditions. This is where NS1 comes into play.

While our Next-Generation DNS in its most basic form can provide appreciable gains in performance, and allow for intelligence to be injected into a protocol that was designed for static routing, solving the aforementioned challenge is a job for Pulsar, a real user monitoring (RUM) solution that’s integrated with NS1’s DNS platform. Pulsar takes billions of actual daily measurements to create a hyper-accurate map of the internet, designed to continually optimize traffic steering.

Where redundancy plays a strong role in the deployment of any mission critical resource, we can make the reasonable inference that an enterprise would choose to leverage at least two, if not more, cloud providers to ensure high availability. Pulsar not only allows for the effective selection of these services at the time of deployment, but ensures that every DNS request that comes in for that resource is routed to the best performing instance of that service.

In this example, we’re going to look at AWS East and West availability zones from the vantage point of all users located in Kansas. Kansas was a good choice for this example, as it’s in the middle of the continent, but this situation applies in other cases where data centers or cloud availability zones are coastally distributed. In a distributed application, having a presence in these availability zones ensures that customers in all places in the country are able to access the application quickly. Pulsar arbitrates which resource is chosen based on latency. The latency is derived from community based RUM data that comes from resources that have been instrumented with a Pulsar javascript tag, that sends back information about how certain ISPs interact with resources hosted in the same environment.

This chart shows the number of Pulsar steering decisions, broken out by 30 minute time intervals. The red line shows decisions for the west coast endpoint, and green shows the east coast endpoint. For a couple of hours, users in Kansas were being sent primarily to the East availability zone. Between 06:00 and 08:00, we see the West availability zone taking more of the traffic, and eventually taking more than the East availability zone around 09:00. Shortly thereafter, we see an inverse situation where the East is suddenly having to take the majority of the traffic while the West dropped. These routing decisions from Pulsar were reactions to overarching network conditions, normally outside the scope of a traditional DNS-based load balancing solution.

Result: Given the specific data set for June 29th, 2018 between 00:00 and 16:00, monitoring traffic between AWS East and West availability zones for traffic coming from Kansas, the traffic was split 85% East, 15% West.

If you’re interested in learning more about Pulsar, and what it can do to improve end-user experience for your business, feel free to reach out to us. We’ll be happy to show you what Pulsar is capable of!