Full Stack Delivery Networks
Content Delivery Networks or Content Distribution Networks (CDNs) comprise a critical layer of the internet ecosystem. Being able to serve content quickly and easily to users all over the world, without untenable latency, has contributed immensely to the global availability and accessibility of the internet. If it weren’t for CDNs, you probably wouldn’t be reading this blog — you’d still be watching the page load.
CDNs have meaningfully reshaped the tech industry in terms of asset delivery, but what about the rest of an application? Why aren’t there any CDNs for full stack applications?
Let’s take a look at CDNs, what they are, and where we think they’re going.
A Closer Look at CDNs
Before we dive into the future of CDNs, let’s take a quick look at what we mean when we say “CDN.”
On a technical level, a CDN is a network of linked servers that cache content like images, videos, and even entire web pages in proxy servers near to users’ physical location. This allows users to do things like stream movies, use social media, and read blogs like this one without having to wait for content to load from the origin server where the content is originally hosted.
The key differentiation between a CDN and a standard server network is the strategic placement of CDN servers and the highly distributed nature of the system. Basically, CDNs are waypoints placed between users and origin servers in order to make content more quickly and easily accessible by users, regardless of where in the world those users are.
Why CDNs?
CDNs are incredibly popular, and it’s not hard to see why. Using a CDN provides a better experience for users everywhere by minimizing website load times, keeping websites available via load balancing, and improving a site’s overall security (specifically against DDoS attacks).
For our purposes let’s focus on the most relevant benefits steering the future of CDNs: the developer experience, reduced latency, increased availability, and reduced cost.
Developer Experience and Automation
Critically, a CDN automates a lot of work previously managed by developers to deliver significant benefits to the user without an equally significant engineering lift. Dynamic global scaling, load balancing, and rerouting in times of outage are all managed by CDNs, shifting the focus away from the nuts and bolts of content delivery. There’s an element of “it just works” with CDNs that typifies the grander industry motion toward abstraction with PaaS and FaaS offerings. All the benefits we focus on and discuss in this section require very little manual work to enjoy.
Reduced Latency and End User Quality of Experience
The most obvious benefit of using a CDN is the reduction of latency and the resulting reduction of load errors, time-outs, and user complaints. If you’ve ever tried to watch Netflix with bad wifi, you already understand why minimal buffering is so key for content delivery.
Most of this low latency is achieved by reducing the actual, physical distance between users and the content they’re trying to access. If the requested content is cached across the network, it can be accessed from the nearest CDN server with minimal delay. The user is only pulling from the server that’s local to them, so the data isn’t traveling thousands of miles.
If the requested content isn’t cached, or is dynamic and therefore cannot be cached...hold that thought for now.
Reduced Cost
Cloudflare has spoken publicly about AWS’s egress costs, not least of which because CDNs can be used to significantly reduce them. Web hosting services charge for bandwidth — transferring data to or from an origin server — but if content is cached within a CDN then less data needs to be transferred. This naturally saves users a significant amount of money and makes billing more predictable, as estimating data traffic costs currently requires 11 pages of reading and multiple tools.
Availability and Load Balancing
A CDN is distributed by nature, meaning different users in different geographies aren’t necessarily accessing the same server — or, more accurately, it means they don’t have to access the same server.
A CDN balances traffic between available resources to ensure that performance for every user is optimized based on factors including where they’re located, what they’re trying to do, and which servers are currently online. This plays into the latency point discussed above, but it also plays a critical role in a website’s availability.
If, for example, a CDN server goes down the CDN can reroute users (who would normally access that server) to the next available server. The user experiences no interruption of service for the duration, allowing the issue to be resolved without downtime. This also applies to origin servers, as CDN providers can support upstream server failures for their customers.
Even outside instances of outage, a CDN can both ensure availability and optimize for performance. In cases of network congestion where one server is experiencing a high volume of traffic, that traffic can be rerouted to other servers with less congestion.
The Evolution of the CDN
Over the past decade, CDNs have evolved beyond simple image caching to encompass more advanced functionality.
CDN caches can now run scripts that generate and deliver previously uncacheable dynamic content to users based on factors like time of visit, location, and device type. This content can also be interactive, allowing pages to change in real time based on user behavior. By combining static and dynamic content caching, a CDN can deliver a fully interactive website with minimal latency.
CDNs can also perform broader logic computations at edge locations, providing additional power and flexibility. It’s possible to input custom caching logic, split a single request across multiple servers then combine the responses, and modify content at the point of delivery and ingestion. Some CDNs can even respond to stateless requests directly from the edge without contacting the origin server. Modern CDNs behave less like simple waypoints and more like a distributed intelligent network.
There is a clear push, both from the market and from CDN providers like Cloudflare, to use the CDN model to deliver more than static content. Zeroing in on recent “CDN plus” offerings like Cloudflare Workers is an interesting exercise. Workers provides a lightweight JavaScript execution environment to augment existing applications or create new ones and is marketed overtly as a way to deploy serverless code.
The selling point is, specifically, being stacked on top of Cloudflare’s “high performance global network.” The value lies in how these lightweight serverless applications are delivered, which is on top of Cloudflare’s CDN infrastructure.
Compare this to AWS Lambda, another serverless compute service often pitted against the Cloudflare Workers offering. When compared directly, time and time again, the value of Workers lies in performance and availability which are the same core benefits of a traditional CDN. The sheer number of supported regions is often cited as Cloudflare’s edge despite services like Lambda providing more functionality and flexibility. AWS Cloudfront, which functions more like Cloudflare Workers and has a larger network, enjoys a more favorable comparison.
Another interesting, oft lauded feature of Workers over other serverless platforms is the ability to run very small, self-contained applications. This has profound implications for the direction of the market as a whole. Consumers don’t just want to run their code closer to their users, they want to run entire applications closer to their users.
Market Insights and Current Limitations
The success of tools like Workers, the specific features that enjoy acclaim, the way the tool is marketed, the overall movement of CDNs from static content delivery to lightweight compute platforms — all of that comes together to form two big conclusions:
- Organizations want their applications running closer to their users
- Organizations want their applications to be highly available
Solutions like Cloudflare Workers, AWS Lambda, and AWS Lambda@Edge have done a lot for transforming the classic CDN, but they’re still only stepping stones toward CDN style app delivery.
While current CDN platforms can be a good choice for extremely small and otherwise lightweight serverless applications written as many interacting and independent functions, the majority of applications (especially enterprise and cloud native applications) are containerized. Shifting from a containerized monolithic or microservice application to a serverless architecture is a significant lift that often requires costly back-end rewrites. Writing and then wiring together independently deployed and invoked javascript functions just isn’t an option for every piece of software.
Speaking of functions, they’re smaller than containers. This is fine for the aforementioned small serverless applications, as individual functions will have minimal latency, but as an application gets more complicated and requires more functions calling other functions, latency begins to stack and impede performance. Cold starts can also introduce challenges dependending on the provider.
CDNs, even ones with a large footprint, are still single-provider networks. The resources of any single provider aren’t always consistent and available across all locations, and cannot provide the level of compute at the level of coverage necessary to run full stack applications in the same global way they can serve content to end users. Many applications also require or otherwise benefit from specialized resources in a way content delivery does not, like GPUs for ML inferencing. A single provider is unlikely to have every possible resource in every possible place to support every possible type of application. Even if an application starts small enough to run on a CDN, as that app scales it will quickly outgrow even the largest CDN provider.
All of this begs the question — what does a full stack CDN look like?
The Full Stack Future of CDNs
There are obvious trends pointing toward a future where compute is local, edge and cloud resources are combined to form end-to-end networks, and highly available multi-region and multi-cloud deployments are the norm. Taken in conjunction with our discussion about the evolution of CDNs above, all signs point to one thing: CDNs, but for containerized applications.
What would a Full Stack CDN look like?
A lot like a CDN! Cloudflare’s CDN backbone is core to Cloudflare Workers and provides a huge portion of its overall value. If the CDN model of “servers everywhere all the time” isn’t broken, there’s no need to fix it.
Of course, a global network that could support full stack application delivery would need a lot more capacity than your average CDN in order to handle the computational load of hundreds of millions of containers. This network would therefore need multiple data centers in every country, and preferably in every region, to provide redundancy in case of outage or failure. Static web content is more lightweight than a container, so while you can get away with far flung reroutes on a CDN, it’s best to err on the side of caution when it comes to applications. Laying out these requirements, it’d be prohibitively difficult to build a global network from the ground up. Luckily, a global network already exists (albeit fractured) in the form of public clouds, bare metal providers, and edge.
If every public cloud could be combined and used in tandem with edge networks and edge deployed servers and regional/local bare metal providers as a single, contiguous, end-to-end resource, it would closely mimic a modern CDN in terms of interconnectivity, availability, and redundancy. This singular resource pool forms the backbone of a full stack delivery network with the added benefit of being open and provider agnostic. A system that uses multiple resources dynamically as conditions change captures the automated routing piece of the traditional CDN and produces the best possible developer experience. Working across diverse infrastructure, locations, and providers is massively beneficial given the fluctuating constraints on availability and cost that restricting to a single CDN or cloud provider produces.
However stitching together two clouds, let alone every public cloud, isn’t possible from within the cloud layer. Every cloud has their own requirements, limitations, and services that don’t translate well from one provider to the next. Instead, a new layer would need to be built above the clouds in order to coordinate deployments across them. This is similar to the way current CDNs use PoPs to cache and relay data instead of replicating and connecting multiple origin servers for every individual customer.
But having a layer that allows for coordinating deployments isn’t the same thing as having a mechanism for coordinating deployments. This brings us back to another major strength of the traditional CDN; load balancing and routing. Imagine if every application could be moved seamlessly across clouds and edge networks the way data is moved across CDNs.
If applications could be delivered in a similarly automated and optimized way, every system would be fault-tolerant and every user would enjoy a much higher quality of experience. The coordination layer would therefore need built in autoscaling and load balancing which is abstracted away for users in the same way it’s abstracted away on a CDN.
As we mentioned previously, all benefits provided by CDNs are done in an automated, fully managed fashion. A full stack delivery network should do the same.
Finally with all the infrastructure abstracted away you’d need a platform where users could manage deployments and control for things like cost, hardware preferences, regulatory zones, and data locality. For CDNs there are products like the aforementioned Cloudflare Workers that provide a level of visibility and control for users. For containerized application delivery there’d need to be a similar platform resting on top of everything we’ve previously discussed.
Coincidentally, that’s exactly what we’re building at Seaplane.
Conclusion
CDNs are a vital piece of the internet as we all know it, and they’re consistently pushing beyond the boundaries of simple content delivery. We believe the CDN model — one of low latency and high availability — will eventually be used as the de facto way to deliver full stack applications.
While there have been many small steps in the right direction with products like Cloudflare Workers and AWS Lambda, there’s still a large gap in the market for a true application delivery network. A gap we’re actively working to fill with our own user-centric control plane.
If you’d like early access to our global app delivery platform you can contact us below. For updates on what we’re building and where we think the industry is headed, subscribe to our newsletter.
