Skip to main content

Fastly - CDN

The Fastly CDN product is, broadly, two things:

  1. A pull-based CDN that can pull off some edge compute-esuqe smarts.
  2. An edge compute platform that can be programmed to behave like a traditional pull-based CDN.

Let's start with 1, and talk about a piece of software called Varnish.

Varnish​

Fastly launched in 2011, but it wasn't built from the ground-up. The core piece of infrastructure that powers Fastly is Varnish, a piece of open-source software that implements a, you guessed it: caching reverse proxy. From the Fastly documentation itself:

Fastly's cache servers run an evolution of Varnish which diverged from the community project at version 2.1.

Reverse proxies had existed long before Varnish. Common web servers like Apache and nginx can be configured to run as reverse proxies, and specialised caching proxies like Squid have long-existed as well. Varnish differs from its predecessors predominantly in two ways:

  1. It focuses on HTTP, and reverse-proxying such.
  2. It's far more programmable than other offerings.

The narrow focus on HTTP reverse-proxying allows it to exclude the complexity of supporting other non-HTTP use cases, e.g. Varnish isn't designed to be used as an FTP proxy. The programmability, on the other hand, allows it to support more complicated usage patterns within the realm of HTTP reverse-proxying.

Varnish presents a model of the HTTP request/response cycle as a state machine, where custom configuration code can be executed as the machine progresses through these states.

The Varnish (and Fastly) State Machine​

As a refresher, a state machine is a model of computation where the "machine" can be exactly in one state at a given time, and inputs drive defined transitions from one state to another. State machines are commonly illustrated using state diagrams. Here's a non-exhaustive example of one that illustrates the state of a single-speed bicycle:

A Terrible Bike

The bike starts Motionless. If we Pedal then it enters and stays in the state Locomoting. If we're not pedaling, we're Coasting. If we Pedal while Coasting, then we're Locomoting again, but need to keep Pedaling to stay that way. If we're Coasting and not Pedaling, then we'll eventually end up Motionless again, you know, hills notwithstanding. We can't jump straight from Motionless to Coasting without transitioning through Locomoting by Pedaling–this is an acoustic bike, not an electric one.

Okay. Here's the state machine for the latest version of Varnish, taken straight from the Varnish docs:

Varnish State Machine

The state machine Fastly uses is a little simpler than this. For example, a single vcl_fetch is in place rather than vcl_backend_fetch. Fastly offers a vcl_log that we transition to once the response has been sent to the client. The idea is the same, though–a state machine that we transition through as we process the request and response. Varnish (and by extension, Fastly) allows us to customize its behaviour by writing subroutines that are invoked as these transitions occur.

Fastly have provided a handy playground tool called Fastly Fiddle that allows us to demonstrate this by calling a log subroutine to emit log statements. Try clicking the Run button below and notice the log statements emitted as the request is processed.

warning

If the Fiddle above isn't loading, try reloading this page. Apologies from the author, who hacked this React component together quickly to get something working.

info

init is not part of the request cycle but is run once when the VCL code is loaded. It's not valid to call log in init, which is why we have not.

Don't worry, VCL will be explained in more detail later in this documentation.

The states that are available for us to hook into with custom code give us a good amount of leeway in how we decide to respond to a request. For example, here's a simple Fiddle where, on a random basis, 50% of the time we return a 404 without ever making a request to an origin, and the other 50% of the time we normally process the request by either returning a cached response or forwarding it to the origin.

Having these states be well defined, as well as the possible transitions between them, allows us to safely compute the proper response to a request. For instance, it wouldn't make sense to try and do a cache lookup when we've already entered vcl_deliver, may have contacted the origin, and are about to return a response to the client.

This is how we build advanced CDN configurations in the VCL-based Fastly CDN product. Based on what we're trying to accomplish, we determine the appropriate places to hook into the request and response processing flow, and then we write VCL code to carry out our logic.

So, about that whole VCL thing? We'll address that in the next section.