Few web hosting platforms, serverless or otherwise, operate their own content delivery network (CDN).
Webslice has been running its own CDN for a couple of years now, but we’ve never taken the time to tell the story of why we do it.
We’d wanted to build our own CDN for a while. At first we relied on an off-the-shelf CDN provider that was good enough while we were developing the platform. When that vendor suddenly closed shop, we were left needing to move things along much faster than we’d ever anticipated. Although unexpected, it was the push we needed to build a custom CDN tailormade for Webslice Serverless.
Why Webslice needs a CDN
Webslice Serverless is built on top of AWS infrastructure. It’s designed to help you run and scale websites without ever having to worry about configuring or managing AWS services like Lambda, EC2 and ECS. With a CDN running on top, Webslice Serverless can cache data on the edge to serve traffic without spinning up any AWS instances (and no AWS instances means no AWS usage costs).
In case you need a refresher: a CDN is a group of geographically distributed servers whose main function is to cache content close to the end user. Visitors are served content by the closest CDN node to them, rather than trying to load data from the other side of the globe.
Caching content on a CDN makes your site faster for visitors and, in the case of Webslice Serverless, can make sites cheaper to run. More effective caching means less AWS usage, lower bills and less latency.
When we launched Webslice we knew we’d eventually want to run our own CDN. We also knew there’d be some extra work to get it working the way we wanted alongside AWS.
When you’re building a new product or platform, you have to make some hard calls about what goes into v1. In the early days of Webslice, that meant leaving our vision of a homegrown CDN on the to-do list.
Before we had our own CDN
Back in 2020, we were using a CDN provider called Stackpath. They were a good enough solution for us at the time, and it was the quickest way to get a CDN up and running on the platform. Because of Webslice’s breadth of functionality, and the way it interacts with AWS, getting Stackpath working how we wanted meant stepping over hurdles and omitting some functionality. It also meant sacrificing some control of configuration and pricing.
And then, at the end of 2023, after 3 years of using their service, Stackpath unexpectedly told us they were shutting down their CDN operations. We had just weeks to sort out a replacement. Thankfully, we’d been planning to build our own CDN this whole time.
More than flicking a switch
While lots of other stranded Stackpath customers switched to big CDN vendors like Cloudflare, it was never going to be simple for us to change CDN. The way Webslice Serverless interacts with Lambda makes using off-the-shelf solutions difficult and limiting.
CDN vendors were either restricting Webslice’s functionality because of their technical shortcomings, or they were demanding enterprise pricing to work around them. One technical sticking point was that most CDN providers had a payload limit of 6MB. This limit is a hard blocker on uploading files larger than 6MB to Lambda. It’d stop you from being able to do things like adding a video to your site. There were other obstacles too, like a requirement for Lambda query strings to be formatted in a very particular way.
We didn’t want to put arbitrary restrictions like that on Webslice Serverless users. If we’d chosen to try and use an external CDN provider, we’d be at their mercy. We’d either be waiting for them to to roll-out changes like bigger payload limits, or paying eye-watering enterprise pricing for custom workarounds.
We could also have taken a piecemeal approach and slapped on a new plugin for each incompatibility edge case, but that wasn’t a realistic long-term fix either. Something as simple as one out-of-date plugin could take down the whole CDN.
It was finally time to build our own CDN. We backed ourselves to create a new feature that customers would benefit the most from, rather than taking the easy way out and forcing limitations on them.
The story of how we went about that particular project is worthy of its own article. What’s important here is that we got our first version up quickly enough to take over from Stackpath, and that we’ve been iterating on it since then.
Benefits extending to the edge
Since early 2024 we’ve had our own CDN serving traffic. In the two years since, we’ve been constantly updating and making improvements so you can get more and more out of it.
Not many hosting platforms run their own CDN. We do though, and it has perks for everybody shipping websites on Webslice Serverless.
As well as serving traffic faster for latency reasons, using our CDN is good for keeping your bills low. One way we do this is letting you use our CDN to serve all your Webslice Serverless static content for you. Configuring your site to Cache All Static Files tells the CDN to cache and serve all your static content, which we went deeper into in an earlier blog post. Everyone can take advantage of a well-optimized CDN handling edge caching and driving down expenses, especially when it’s built specifically for the platform you’re hosting with.
Since we’re running our own CDN, when we want to add new features or refine the network to reduce your AWS usage, we can. One feature that we’ve added recently handles 301 connections at the edge before hitting AWS. This new change means there’s now no AWS usage with 301 redirects, as they’re instead handled entirely by the CDN. It’s a small improvement that reduces Lambda latency by avoiding the Lambda altogether.
That’s just one example of a CDN feature that has a bigger payoff in Serverless environments. It’s exactly the sort of idea that a third-party provider would deprioritize. But for us and our users, it’s a total no-brainer.
Operating our own CDN is the best way for us to add new features like this to the network, and provide a Serverless platform that helps you ship and scale sites. We’re serving content from the Lambda with solutions for some of the limitations you’d find on other CDNs.
A change for the best
Today, our in-house CDN is a major strength of Webslice Serverless. Perhaps we should be thanking Stackpath for pulling the plug when they did.
As a Webslice customer, the interests of your CDN provider align with the interests of your host, whose interests align with yours. You care about performance, we care about performance, and since we control your CDN that care extends all the way to the edge.
Neither of us want AWS costs to be higher than necessary, and managing our own CDN lets us keep those costs down.
If you want to give it a go you can spin up your first Webslice Serverless project today and we'll add $5 to your account. Check out our docs to read more about our CDN.