The use of multiple content delivery networks (CDNs) is on the rise as enterprises look to improve the performance of their applications, limit downtime, and reduce costs where possible. A number of factors are driving this trend. Adding redundancy to their IT stack ensures there is not one single point of failure that can bring services and products down, costing them valuable revenue and customer loyalty. Companies expanding to new service areas often leverage multiple CDNs because performance in certain regions can be unreliable. Others seek to avoid vendor lock-in as a way to minimize both financial and technical risks.
Enterprises pursuing a multi-CDN strategy have a plethora of options to choose from and can often struggle to determine where their search should start, what exactly they need, and how to prioritize investment. Seeking answers to the following questions will ensure the resulting multi-CDN strategy is successful from the start:
1. What exactly are you optimizing for?
As with any technology, CDN providers have different value propositions. For example, one provider may best support the hosting of static assets for web applications, such as a mortgage calculator, while another may be a better fit for streaming video. Organizations should leverage these areas of expertise to their advantage.
If an enterprise isn’t entirely sure where to focus its optimization efforts, leadership should seek feedback from similar customers or ask the provider for reference points to guide decision making. IT teams should consider what pain they or their users are feeling. Is an application or service the company runs experiencing outages or performance fluctuations? Is there a geographic-specific need to fulfill? Perhaps the current CDN provider is simply too costly. Moving to a multi-CDN strategy gives you the flexibility to negotiate in the regions where performance is suffering.
Another element enterprises should consider is who they are looking to serve. A growing customer base can be one reason to bring on additional resources. One vendor may have been enough to support a startup’s customer base, but as that organization matures and grows, so will its content delivery needs.
2. Where are your users located?
The location of end-users is another key factor in determining which CDN provider to select. Many larger CDN vendors have global offerings that can address basic redundancy needs and ensure applications continue to run if the primary provider experiences an outage. However, the price point or regional performance limitations may impact the decision. Rather than paying a premium price for services offering subpar performance, consider working with a vendor in that local market that can offer a better price and superior performance for regional users.
Many successful enterprises leverage multiple CDNs to achieve the best global performance based on where users are located. One vendor may meet performance needs in North America, or the Northeast specifically, and another local vendor could be better equipped to deliver the application in question to customers in Asia or Africa.
3. What kind of content is the organization serving up to customers?
The type of application content an enterprise offers is an important consideration. Static and dynamic content, such as live video or APIs, have different needs, and so the solutions that support them will also differ. Choose a CDN based on its individual strengths and ability to support the content needs of the organization. This might mean selecting one provider to serve web application assets and another to host video content.
4. What metrics and reporting will you need access to?
The analytics features and reporting capabilities of CDN providers vary greatly. Any single provider's options might not map to an organization's unique needs. Before researching new CDN providers, enterprises should define which metrics are important to them. Does their current provider's reporting meet their needs? Why or why not? Consider how often the IT team wants to receive reports or view those metrics. Do they need real-time access, or is hourly or daily access to logs sufficient?
5. What happens when you test your actual traffic on this CDN?
A final part of any decision-making process should be testing. Often, CDN providers offer estimates around their average performance and uptime, but a trusted vendor will allow a potential customer to test and monitor their actual application traffic. Initially, send 10 percent of traffic to this vendor and watch what happens over long periods of time. Make sure to conduct testing during both peak and off-peak time periods to get an accurate picture of how the application in question fares on this CDN in varying environments. In addition to helping organizations gain confidence in their decision, this testing period can also help them negotiate come decision time. They will have a better understanding of what commits will be required of the partner and what SLAs the provider will be responsible for upholding.
A multi-CDN approach offers cost and performance benefits as companies grow and expand globally, and there are many considerations to be made when selecting providers. The above questions can help guide the selection process by providing IT teams with a deeper understanding of a provider's ability to meet the organizations' unique needs. Armed with this knowledge, they can be sure they select the multi-CDN architecture that will minimize costs and risk while delivering optimal performance.
Subsea cable alternatives can provide a level of comfort for those concerned about disruptions. Realistically, they will continue to play a small, but critical role in the short term.
Maintaining existing network infrastructures often incurs huge technical debt before newer technologies are adopted over time.
Amid ongoing regional uncertainties, telecom infrastructure in the Middle East has expand to include terrestrial low-latency network infrastructure, which offers resilience and agility in navigating political complexities without relying solely on undersea networks.
