Containers Have Made It Easy to Build Your Own CDN. Should You?

Building your own Content Delivery Network, or CDN, was once feasible only for major companies with large budgets and development teams. But thanks to containers, it has become practical for anyone to deploy a self-managed CDN in order to improve latency for Web apps.

The question for many teams has now become whether it’s worth deploying your own CDN, or sticking with the traditional approach of working with a CDN provider. Here’s a primer on what to consider when making that decision, and what to expect if you opt for a DIY approach to your CDN.

Traditional CDNs

CDNs, which have existed since the late 1990s, perform a basic yet critical function for organizations that need to make Web apps or other content available to users who are spread across a wide geographic area. A CDN distributes copies of the content across a network of geographically dispersed proxy servers. That way, when a user in a given location issues a request for content, the content can be served by a server that is geographically proximate to the user. This generally leads to faster content delivery and thus, a more positive end-user experience.

Traditionally, building a CDN required a lot of resources and time. You had to set up a network of servers in different geographic regions, then provision them with a software framework that could distribute the content efficiently to users in different areas. This was no mean feat, given that there is no CDN platform that you can simply install yourself. Instead, building an effective CDN required a lot of custom development, as well as extensive manual management of network routes, DNS configurations and the like.

That’s why, traditionally, most organizations that needed the features of a CDN turned to vendors who specialized in providing CDN services, like Akamai or AWS CloudFront. These vendors did the hard work of building and managing CDNs. Unless you were a company like Google or Netflix, it simply wasn’t feasible to go out and build your own CDN.

Containers and CDNs

Containers have changed this. By offering an easy way to package a CDN platform and distribute it across a network of servers, containers have made it practical for smaller teams to launch their own CDN.

Today, teams who want to build their own CDN can do so relatively easily using an open source tool like KubeCDN, which uses Kubernetes, Terraform and AWS Route53 to set up CDN networks spread across multiple AWS regions. CDN in a Box, a Dockerized version of the open source Traffic Control CDN platform, does something similar, albeit not using Kubernetes.

For organizations that don’t want to rely on the public cloud to host their CDN infrastructure, it’s also possible to use a distributed colocation provider, like Equinix or Packet, then use Platform9 to orchestrate deployment of a Kubernetes-based CDN on it.

The value that containers bring to CDN is not limited to the standard benefits of containers, like flexibility and reproducibility. The biggest advantage lies in the fact that containerized CDNs are very easy to deploy. Instead of having to wade through a morass of obscure software and custom configurations to get a CDN up and running, you can simply take a solution like KubeCDN and deploy it on a public cloud. Most of the tedious setup and provisioning is handled automatically (through Terraform, in KubeCDN’s case), and the CDN framework is built into the platform.

Benefits of Running Your Own Containerized CDN

Just because you can now run your own CDN with the help of containers, though, should you?

The answer to that question depends largely on whether conventional CDN services (like, again, those from Akamai or CloudFront) are a good fit for you.

Conventional CDNs have some clear drawbacks:

They cost money. The exact cost varies widely depending on which CDN provider you choose and how much content you host; but it’s likely that using a CDN provider will cost more than self-hosting a CDN.
Traditional CDNs may create some privacy or even compliance issues because they require you to share your content with a network that you don’t control yourself. In other words, if you want to use a CDN like Akamai, you need to trust Akamai with your content.
Occasionally, CDNs may be blocked by network filters, making your content inaccessible to users governed by those filters.
Although most major CDNs offer content hosting options in a wide variety of locations, they don’t give you total control over exactly where your content will be hosted. This could create issues if the CDN provider’s network is not configured in a way that works best for the users you are trying to serve. You may know more than your CDN provider about where your users are located and where proxy servers should be set up, but without direct control over the CDN network, your ability to configure the ideal setup is limited.

On the other hand, compared to self-managed CDNs, traditional CDNs offer at least a few advantages:

They are easier to set up. Although solutions like KubeCDN are a huge step forward in making self-managed CDNs easier to create, they still require more effort to deploy and manage than a conventional option.
They provide the infrastructure as well as the CDN software. With a self-managed CDN, you have to provide your own infrastructure. In most cases, you can use a public cloud, so it’s not particularly hard to obtain the infrastructure. Still, acquiring the CDN infrastructure is an extra step when creating your own CDN, and it creates an expense that you need to factor in when calculating your CDN’s total cost of ownership.
They are mature platforms. Solutions like KubeCDN are much newer, and not yet battle-tested.

Deciding whether to launch your own CDN, then, hinges on whether the benefits of a conventional CDN outweigh the drawbacks for you. Overall, teams who need a large-scale, highly reliable CDN are probably best off sticking with the traditional approach, at least for now.

But for smaller organizations, containerized, self-managed CDNs offer an intriguing opportunity. Maybe your user base isn’t yet large enough to justify the cost of a massive CDN, but you still want to be able to improve content delivery speed a bit. Experimenting with your own CDN built on a platform like KubeCDN could be a good way in this case to dip your toes into the CDN waters, without the cost or commitment of a traditional CDN.

Likewise, self-managed CDNs are valuable for organizations whose users aren’t well served by traditional CDNs. If your user base is concentrated in regions that conventional CDNs aren’t great at covering, you could set up your own CDN based on infrastructure that is closer to your users. Or, if network issues mean that traditional CDNs are blocked for your users, a self-managed CDN is a good solution.

Conclusion

Containerized CDNs have significantly lowered the barrier to entry for organizations that want to launch their own CDN. Although a self-managed CDN is not the right choice for everyone right now, I suspect we will see more and more organizations take this route as platforms like KubeCDN mature, placing into the hands of the masses another type of technology that was once accessible only to Web-scale companies.

Author
Recent Posts

Platform9

Platform9 is the only container management and orchestration solution that supports the complete lifecycle of the cloud-native journey on infrastructure anywhere. Our unique management plane simplifies operations, including observability & monitoring, increases uptime, minimizes costs, and scales as you scale. Built on open foundations, our platform enables enterprises to keep up with the ever-changing cloud-native ecosystem. Our cloud-native wizards provide Always-on Assurance™ every step of the way to ensure a smooth, simplified journey. Innovative enterprises like Juniper, Kingfisher Plc, Mavenir, Redfin, and Cloudera achieve 4x faster time-to-market, up to 90% reduction in operational costs, and 99.99% uptime.Platform9 is a better way to go cloud native, paving the way for an open distributed cloud