VictorOps is now Splunk On-Call! Learn More.
Load balancers and Content Delivery Networks, or CDNs, are both critical tools for delivering modern, cloud-native applications. They play essential roles in ensuring the smooth flow of data between applications and end-users.
If you don’t have both a load balancer and a CDN in place, you’re probably in a poor position to guarantee the uptime of your application across a wide geographic area.
That does not mean, however, that load balancers and CDNs do the same thing. They fulfill similar roles, and their functionality overlaps to some extent. But, they’re different types of tools.
In order to understand the unique roles that load balancers and CDNs play in delivering modern applications, keep reading for an overview and comparison of each of these types of tools.
A Content Delivery Network, or CDN, is a network of servers spread across a wide geographic area. Each server within a CDN hosts the same application or data, or certain parts of the service.
CDNs shorten the time required for a server to communicate with a client by reducing the geographical distance between the server and the client. This is true for two main reasons. First, more distance between endpoints means data takes longer to travel across wires. Although, on modern fiber optic cable where data travels at the speed of light, the time required to send a packet across the United States is only around 0.05 seconds. Second, the greater the distance between a server and its client, the greater the number of routers and repeaters that separate them. Each router and repeater can introduce a delay as it accepts and forwards packets.
If one of the servers in your CDN goes down, other servers on the CDN will still be up and able to serve the content. A CDN isn’t the only way to maximize data availability, but it can help.
In certain cases, CDNs can help overcome access restrictions to content. For example, if a firewall blocks a client machine from accessing a server in one country, a CDN network can provide copies of the content in another country. (There are also some interesting strategies involving the use of CDNs to combat digital censorship.)
It’s worth noting that a CDN is not strictly necessary for delivering an application across a wide geographic area. If your only servers are in California, clients in Thailand will still be able to connect to them. But, the response time for those clients will likely be slower than if you had a CDN that extended into Asia.
A load balancer is a device that automatically distributes network traffic across a cluster of servers (all of which are usually located in the same data center, although some load balancers balance traffic across multiple data centers). A load balancer could be an actual standalone hardware device, or a software application that runs on other networking hardware.
The goal of load balancing is to ensure that requests for an application or data are spread evenly across the network of servers that hosts the application or data. If you have, for example, five servers that each host an instance of your application, you don’t want to have one of them handling all the requests (and possibly failing to respond quickly because it’s overwhelmed with traffic) while the other four sit idle. Instead, you want to distribute the work across all five servers in order to avoid overburdening any of them.
Load balancers also help to ensure uptime by redirecting traffic to another server in the event that one server goes down.
Load balancers can operate on different network OSI “layers” depending on how you want to filter traffic and make decisions about how to filter it. For example, a load balancer could operate on layer 4 by filtering traffic based on IP addresses, or on layer 7 by filtering based on HTTP header data. There are also different types of algorithms and strategies that load balancers can employ to decide which data is sent where.
CDNs and load balancers have some traits in common. Both of them:
However, their similarities end there. At the end of the day, CDNs and load balancers are fundamentally different types of tools. The main purpose of CDNs is to distribute content across a wide geographic area, whereas a load balancer distributes traffic across a network of servers that are usually in close geographic proximity to each other.
Should you choose to use a CDN, or a load balancer? The short answer is that, if you are delivering a production application to a significant number of users, you probably need both. A load balancer will let you distribute your application across a cluster of servers, which is important for optimizing uptime and performance. A CDN, meanwhile, will help you optimize the experience of end-users in disparate geographic regions.
There might be situations where you need a load balancer but not a CDN. For example, when hosting applications for a city agency whose user-base is large enough to require a server cluster and load balancer but most of whose users are in the same geographic area. Or, you might have a situation where you need a CDN but not a load balancer (for example, you have a geographically dispersed user base but there aren’t enough users in any one location to require a server cluster in that location). But such situations are rather rare.
The bottom line: Load balancers and CDNs are both important tools for modern application delivery and hosting, and they both help to optimize interactions between servers and clients. But, they’re different types of tools, and you shouldn’t assume that if you have one, you don’t need the other.
In addition to CDNs and load balancers, check out these additional ways to maintain highly performant, resilient applications and services. Read our free guide, Why DevOps Matters, to catch up on the human element of efficient software delivery and incident management.
Chris Tozzi has worked as a journalist and Linux systems administrator. He has particular interests in open source, agile infrastructure and networking. He is a Senior Editor of Content and DevOps Analyst at Fixate IO. His latest book, For Fun and Profit: A History of the Free and Open Source Software Revolution, was published in 2017.