4 Reasons to Change CDNs or Go Multi-CDN – And Tips for Doing It
April 4, 2016 | Pete MastinThis is the sixth post in a series that covers all 6 steps of the CDN Framework – a guide designed to help you acquire and maintain the best CDN solution possible. Because Cedexis is the expert in multi-CDN, or merging one CDN with another, we asked Pete Mastin of Cedexis to share some insight with us. Depending on how satisfied you are with your current CDN setup, you may need to transition to a new CDN or merge your current CDN with another provider - something called multi-CDN. Whether you think you might be interested in going multi-CDN or moving from one CDN to another, the four points below will help guide your decision. Also, toward the end of the post, I’ll give you some pointers on how to responsibly change or merge CDNs.
Why to Change or Merge CDNsThe four primary reasons people switch CDNs, or undertake a multi-CDN strategy, are related to: Performance, Availability, Cost, and Ease of Use. I'll go over these in detail below.
Reason #1: PerformancePerformance problems can take a few different forms. One problem is related to the growth of your audience; the other is related to Internet Service Providers (ISPs). You have no control over ISPs, but as you’ll see, there are workarounds. Market Expansion The first performance problem involves market expansion. Often, performance degradation is noticed when a business’s audience expands into other regions. This expansion can be the result of new marketing initiatives in regions once untapped. It can also be the natural result of having a great product that people rave about. Consider a business with a stable audience in North America and a growing audience in Asia. If the business’s current CDN is performant in North America but falling short in Asia, the business needs to make changes to its CDN strategy. At this point, many businesses will add a second CDN to augment their efforts in the newer region. To do this, they use a Global Traffic Management (GTM) solution to federate their current CDN and the new CDN together. This GTM solution routes traffic to the CDN that is most performant in that region using performance metrics like Real User Measurements (RUM). ISP Congestion The second performance problem involves ISPs. Within a specific region or country like the United States, one CDN can be much better on a specific ISP than another. If this is the case, you can use a GTM solution to route traffic that is performing better on AT&T, Verizon, Comcast, or any other ISP, to the best-performing CDN. The free Cedexis Radar tool discussed in Step 5 clearly shows that no one CDN is always the best in every region and on every network. If you really want to provide the best performance for your users, the best solution is to merge two or more CDNs together. This can be done using performance-based load balancing to provide the best potential performance. At Cedexis, one way we have learned to represent performance differences between two CDNs is with the S-Curve. The S-Curve shows the relative advantages from the perspective of user experience between two CDNs. You can only know this through Real User Measurements (RUM). The S-Curve looks like this: In the upper left, you see where users of CDN #1 have a clearly better experience. In the lower right, you see where users in that region would have experienced CDN #2 as the better choice. In the middle, you see where both CDNs would actually have produced exactly the same result. When you look at examples from actual locations and ISPs, it turns out that no CDN always wins. There are always users that benefit from being on one CDN or the other.
Reason #2: AvailabilityAnother reason we see companies change CDNs, or merge CDNs, is because they have experienced an outage. There are two types of outages - micro-outages and major outages. Most CDN services have experienced one or both of these. Micro-Outage A micro-outage occurs when a Point of Presence (POP) is overrun or goes offline and traffic is re-routed to suboptimal POPs. They can also occur when there are peering issues or outages between ISPs and CDNs. This happens more frequently. Sometimes this occurs in the middle mile and there’s nothing that the CDN can do about it. Chronic ISP congestion can also play a role. These micro-outages typically last anywhere from five minutes to a couple of hours. And by the time the CDN Network Operations Center (NOC) starts getting calls from customers, the problem has often already resolved itself. If you recall, when recording availability for four different CDN providers in Step 5, we saw a micro-outage occur: Major Outages Major CDN outages are less frequent but can and do happen. DNS outages, Anycast outages, storage failures, and many other failure types can cause long-term downtime. While micro-outages cause slowdowns and poor performance, a major outage typically causes a complete loss of the site or app for an extended period. It’s important to understand that a CDN, like any piece of infrastructure in your web stack, can be a single point of failure (SPOF) and must be treated that way. Best practice is to never allow a SPOF, which means having a CDN failover strategy. If you can implement that as an Active-Active configuration, so much the better. MaxCDN talks about “active” and “passive” multi-CDN strategies in the second section of this post.
Reason #3: CostsMany customers of CDN technology understand that there is a fairly wide range of cost associated to CDN usage. Both the value-added services that CDNs offer, as well as transit costs, vary wildly from provider to provider. We see many customers that want to switch CDNs solely due to cost.
Related Blog Post: What CDN Pricing Model Costs Less?
Related Blog Post: CDN Pricing and Feature Comparison Tables
Reason #4: Ease of UseWhen you want to purge something from the CDN cache, you should be able to purge it. And when you want reports at the request level, file level, or zone level, you should be able to pull them. You should be able to do all this - and much more - with the click of a button. Further, the CDN should also be convenient for engineers and system administrators to use. The CDN should have a robust API with documentation that gives them the ability to troubleshoot and optimize. If the CDN is not easy to use for everyone involved with CDN oversight, a full CDN switch may be in store. Bottom line: If you’re merging CDNs, make sure every CDN is easy to use in your multi-CDN strategy.
Rule #1: Own your OriginWhat I mean by this is that you must maintain your origin outside of any of your CDNs. Many CDNs provide origin services and it is often the easiest way to get started with your first CDN. However, if and when the time comes to move to a second CDN, this type of configuration can be problematic. Not all CDNs allow access to the origin services from the outside. To have the ability on your site to allow multiple CDNs to cache your content, you must first understand your current content delivery ecosystem. The business logic that may live on parts of the CDN has to be pulled back and implemented on the origin. Here are three important things to look for regarding this issue:
- Establish your origin outside of the CDN itself. If your CDN does not allow its storage to be used as third-party origin storage, best practice would be to have multiple origins (at least a primary and a failover). Multiple geo-located origins may be good for larger sites or mobile apps with high data needs (online gaming for instance). These origins can be load balanced as well for performance and availability. An example of this strategy would be a company that executes origins on the East Coast, West Coast, Europe, and Asia.
- Limit the number of features you utilize with a specific CDN. Put the intelligence in your origin when possible. Attempt to use CDNs only for delivery. By putting the business logic back into the origin and performing these tasks yourself, you have set the table for multi-CDN delivery.
- Limit the use of CDN origin storage. This will have to be replicated across multiple CDNs if you use it. Rather, opt for using cloud storage in multiple locations or set up your storage to be near your own origin.
Rule #2: Know Your TrafficIs your traffic HTTP? HTTPS? Large file? Video? What is your traffic type and what mechanisms will make it perform better? Know the answers to these questions. The type of traffic you have largely determines your caching capabilities. There are other factors as well. For instance, large file delivery is usually improved dramatically by increased throughput. So if that’s your use case, optimize for that by selecting CDNs that have great throughput in the regions you care about. Likewise, if HTTPS small object is the majority of what you want optimized, it pays to understand that and federate your CDNs to that end.
Rule #3: Merge ResponsiblyWhen adding a CDN or moving traffic to a CDN, it’s important to do it in a controlled fashion. What we mean here is that the traffic should be moved in a systematic way that provides for a failback at every phase. There are many ways to do this. At Cedexis we have seen customers move all the North American traffic over to one region at a time. We have also seen clients move all their traffic over at 10% intervals. In either case, they had the capability to test the performance of their website or application after the new CDN started taking traffic. They could then determine if performance was where it needed to be before moving the next tranche of traffic. An active-active multi-CDN load balancer (like the kind we offer at Cedexis) can take advantage of costs savings, as well as provide performance improvements and 100% availability.
Related Blog Post: DNS Load Balancing - Comparison of 4 Services