Sep 16 2022
Aug 31 2022
Resource
BlogTopic
Edge DeliveryDate
May 17, 2019One of the hidden strengths of StackPath is its private network backbone. At first glance it’s not obvious, but on deeper inspection, it becomes a key part of StackPath’s strategic vision to build the most secure and performant edge services platform.
Below, I’ll explain how a private backbone works from an edge delivery standpoint, as well as discuss the advantages of using one rather the public internet for content transit.
Not that long ago, the people who design networks liked to refer to a standard configuration as a leaf-and-spine architecture. The idea is that individual leaf nodes, like switches, all attach to a spine composed of big switches or routers—much like the bones of a vertebrate animal attach to its spine.
Similarly, a network backbone connects disparate networks together, giving information a path to travel on from one end of the network to the next. The path is direct (i.e. more performant) and secure (i.e. does not have to traverse the public internet).
For instance, if you have multiple disparate networks—such as two points of presence (POPs) in two cities, each with its own individual leaf-and-spine network—the private network backbone allows you to connect them together.
Some content delivery networks (CDNs) outsource this network backbone to dedicated third parties. Others try to use the general Internet to transfer information between POPs.
At StackPath, we build and run our own backbone network, the same way we build and run our own POPs. These are essential for evolving content delivery and CDNs—an evolution that many, including ourselves, are calling edge delivery.
Content delivery networks use the HTTP protocol which is defined as a stateless protocol under the “GET” method. The fancy word is “idempotent” which means not changing under an operation.
Unpacking this, every individual HTTP GET request is defined to be unchanged. It does not matter how many times it’s called, where it’s called from, or the path a series of calls take between an end user and a destination server.
With this in mind, a CDN that operates two POPs shouldn’t need the POPs to communicate with each other. Each POP should just fetch an object from an origin, cache it locally, and then respond with that object (unchanged) for any request.
This scenario is true for a very simple CDN but false for real world use cases that edge services are trying to solve for.
First, logs must flow between POPs. Control and configuration information must flow between POPs to keep them consistent. Monitoring information must also flow so that server and network status are known at a glance.
Second, a company’s objects may flow between POPs given an origin shield architecture. This is a popular setup that protects an origin server from “request overload” and requires POPs to talk to each other.
In each of these cases, POPs can share information without connecting through a private backbone, but there are risks to using the public internet instead.
Given the flow of critical production and customer information between POPs, securing that data against interception or sniffing by unwanted third parties is critical.
There are many ways to do this, from SSL encryption across the public Internet (which is susceptible to sniffing but at least is encrypted) to devices that encrypt and decrypt on-the-fly (e.g. IPSEC) before forwarding across the public Internet.
But if you control your own private backbone network between POPs, you gain an extra level of security. In addition to encrypting data across it, you reduce the ability of unwanted third parties to sniff that traffic.
In short, by not shuttling data across the public Internet, you decrease the attack surface you are otherwise exposed to.
Controlling your own backbone network also means determining when and how to use it. This means speed, namely lower latency and higher bandwidth.
Instead of sharing any public link which could become saturated unexpectedly or be overloaded at any point in time, private links offer uninterrupted access. They are easier to keep updated to the latest and greatest standards and allow dedicated monitoring.
Private dedicated links also mean dedicated end-to-end points. This reduces the number of hops traffic has to take to the bare minimum between the points you care about, minimizing latencies.
Judiciously choosing when and where to utilize a dedicated network backbone delivers flexibility in solutions. Anywhere it makes sense, the dedicated backbone is there. For customer applications which don’t require it, it’s transparent.
As for new services: StackPath’s backbone offers the ability to bring up an anycast IP on top of its virtualized containers and other edge VMs. With this anycast IP, VMs can directly connect with one another over the backbone.
First, the necessary routing announcements are made externally. Then, the moment information enters a StackPath POP its movements are all made internally, even between POPs.
The simplest CDN use cases don’t require a dedicated network backbone. But anything beyond that and the backbone begins to justify itself.
When you have edge servers terminating connections and application logic being executed within a container at the edge, every POP and service needs to inter-communicate for the application to execute correctly in a secure and highly performant environment.
In modern use cases, the necessity of the backbone shines clear. It is the foundation for the next generation of services.