The importance of delivering fast, high-quality content to internet users around the world has led to an increase in multi-CDN architectures over the past several years. These multi-CDN implementations were typically the exclusive domain of media and entertainment companies that serve lots of live and on-demand video, yet multi-CDN delivery is now becoming more common across industries that serve more interactive websites and applications.
The driving force behind this trend is the growing demand for high performance and >99.99% availability, particularly for businesses that rely on low latency and edge functionality. Given the increases in digital interactions, the volume of transactions, and the importance of the internet to businesses across sectors, the practice of delivering web assets now calls for faster, more robust and redundant architectures.
“Whatever you’re doing in technology, it’s only as good as the single points of failure,” Michael Dorosh, senior research director at Gartner, recently told TechMonitor. “Customers have been burned by having servers knocked out by things like outages and cyberattacks. With multi-CDN, if one vendor’s servers are down you can use another’s to reach the outside world.”
However, despite the importance of architecting for redundancy – as well as expanded geographic reach – the resources required to build and maintain an efficient multi-provider system still has many businesses reluctant to incorporate new CDN providers into their stack. Fragmentation in the digital workflow can cause significant headaches for the operations teams that are responsible for managing the configurations and commitments for each vendor.
Still, the fact remains that reliance on a single vendor for web and application delivery comes with serious risk. Should that vendor suffer an outage, it can make your web assets unreachable for large swaths of end users, which will directly impact your bottom line through failed transactions and brand reputation. The true cost of downtime varies widely depending on factors such as industry, business model, average revenue, time of the outage, and other factors.
What, then, are the keys to successfully implementing and maintaining a multi-CDN strategy for websites and applications?
Determine the Best Orchestration for Your Business
Selecting the best process for orchestrating traffic between CDN providers will depend largely on the business and performance goals that you’ve prioritized. Multi-CDN implementations are generally driven by at least one of the following four goals:
- Redundancy to protect against a failure of your primary provider
- Expanded geographic or ISP coverage
- Cost & traffic management
- Real-time performance optimization
DNS-based orchestration is the most common method for routing user requests to a specific CDN for a number or reasons. It’s already a well-understood technology, which means a flatter learning curve for your operations teams. It also requires no additional purchases and installation of hardware or software. Based on the information provided by the DNS resolver, you can set up traffic management policies to point users to specific CDNs based on geographic location, ISP provider, or by percentage of traffic based on your budget and/or CDN commits. DNS orchestration is also able to manage redundancy, as it can reroute traffic to a different CDN if the first option is unresponsive.
The second option, dynamic performance-based CDN orchestration, is not based on static DNS rules, but requires an analytics engine to process synthetic or real-time monitoring data and point the user to the best-performing CDN for that request. This is a common method for video content given that there is typically only a single interaction with the server, but doesn’t work as well for most other types of websites or applications where a user is constantly interacting with various elements on the page. For the latter, the time it takes to make the decision for each request can actually end up hurting the end-user experience.
Find the Right Balance
In addition to the cost of bringing on a new CDN vendor, every new provider in your stack adds another layer of complexity. Each CDN must be properly tuned and configured to optimize the delivery for each region where your end users are located. All of the security and edge services – some of which may be proprietary to that specific CDN – must be configured and regularly managed as well.
There’s also the need to keep the cache warm for each CDN in your stack in the event of failover. This means that even if your multi-CDN strategy is in place purely for redundancy, you want to serve about 5-10% of your most accessed content and URLs from those backup CDNs to ensure that they have the most important content cached at all times. Failure to do this will compromise your backup CDNs’ ability to handle new requests, meaning that when the primary CDN goes down, your origin will be bombarded with the “thundering herd” of requests that can then crash the origin servers and compound your problems.
A multi-CDN architecture naturally has a minimum of two CDNs in the stack, but due to the effort and traffic required to maintain each one, it’s generally a good idea to not implement more than three unless you have specific needs related to volume of transactions and scale that require you to do so.
Prioritize Flexibility
Managing all of your different configurations and edge services within your CDN stack can be complex, but this can be mitigated by using CDNs that make configuration easy. Being able to replicate configurations across CDNs saves both time and resources while also reducing the chances that something goes wrong within a config.
For example, to install a web application firewall (WAF) to protect your application, you might have to purchase a different one for each of your CDNs if they’re only compatible with a single WAF service. But a CDN that provides flexibility at the edge to deploy your own WAF before CDN selection decision is made will allow you to leverage a next-generation WAF provider to minimize the amount of configuration work on the backend.
____
Relying entirely on a single provider for any critical service is a risky bet, and one that’s increasingly unnecessary for CDN services due to continued adoption of multi-CDN architectures across industries. While the complexity of deploying edge services across multiple CDNs can seem like a daunting obstacle to overcome, the right provider will work with you as a partner to help ensure that all of your critical services have sufficient failover and the right configurations across your stack.
To learn more about the Lumen CDN and Edge Application Delivery, reach out to content-delivery@lumen.com.
This content is provided for informational purposes only and may require additional research and substantiation by the end user. In addition, the information is provided “as is” without any warranty or condition of any kind, either express or implied. Use of this information is at the end user’s own risk. Lumen does not warrant that the information will meet the end user’s requirements or that the implementation or usage of this information will result in the desired outcome of the end user. This document represents Lumen’s products and offerings as of the date of issue. Services not available everywhere. Business customers only. Lumen may change or cancel products and services or substitute similar products and services at its sole discretion without notice. ©2021 Lumen Technologies. All Rights Reserved.
Trending Now
You may also like
