mercredi 27 avril 2016

Extra-hints for choosing your CDN provider

Why additional hints? because you can already find a lot of literature on the subject, for example this nice article by Jon Alexander the CDN product manager at Level 3. What I want to add here is some further questions based on my personal experience so you would avoid some surprises later on when you have your CDN contract signed . I'll also bring up the multi CDN question.

So as a number one rule, a map of CDN nodes is simply not enough for making a good decision! It's important to know more in depth these following elements:

  • The most important verification is checking with whom they are networked in your country of interest. For example in Egypt it's mandatory to have a good network capacity with Telecom Egypt who has the largest share of the local market.
  • How are they networked with the Eyeball? for example dedicate private connection is definitely better than IX public peering from performance perspective, but it is more expensive.
  • What is the CDN cluster capacity and its uplink bandwidth?
  • What is the architecture of the cluster? is it a bunch of small servers or a couple of high density servers? are they Squid based or using new beasts like Nginx or Varnish? Indeed, underlying caching engine has an impact on latency and cache efficiency.
  • Sometimes a CDN provider can outperform another even though they do not have a local node for all of the above reasons, so the best way to evaluate is to test!

Now that you know where your CDN provider is present, it is important to know what are its capabilities on these different locations. Is SSL available everywhere? the same question should be asked for any relevant feature for you. Indeed, CDN platform evolves with time through acquisitions, technological updates like any other platform, leading to a heterogeneous ecosystem. Thus you need to verify if your CDN properties will be bound on all locations that are brightly presented by sales :)

As I said previsouly, the best way is to test, but beware of testing biases! First, make sure that your CDN provider has provisioned a trial platform similar to the one you'll be using in your real environment. Then try to evaluate the CDN performance during peak hours, for example in the evening, and under load, because CDN behavior can vary under different conditions. You can use third party analytic tools such as Catchpoint & Dynatrace, but you should understand the limits of their evaluation, because their probes are located in datacenters so they don't reflect 100% the end user experience.

What also makes a good CDN solution is layer 8 in the OSI model: the people! Indeed, when things go wrong, or you want to make critical changes, you'd love to have quick and helpful support. Do you know where is the support team based? their working hours? to which organization they report (regional or global)? any SLA on ticketing? Try to test this as much as possible during your trial.

The last point I want to mention is related to commercial terms. Most of CDN providers have per GB traffic pricing. Make sure that you know what GB you are talking about before comparing prices! is it Egress only? Egress+Ingress? do they bill midgress traffic?
Give some consideration to the commercial flexibility of your provider: what kind of commitment you have? volume/financial/duration? do they offer flexible models that can adapt to your business fluctuations? you can evaluate that during the trial, for example whether the CDN provider is rigid on trial extension, billing start date, feature testing...

Finally I'd like to give you some thoughts on multi CDN strategy. Like any solution it makes sense in certain cases but does not in others. Check Cedexis website for example to learn more about the benefits of multi CDN. In the following, I'd like to highlight some of its limits:
  • Additional costs: Cost of CDN load balancer service, cost of higher CDN rates because of lower commits, cost of additional origin traffic, internal cost of multiple providers management.
  • Increased solution complexity, especially when you have advanced features that requires deeper integration with CDNs
  • Risk of SPOF within the CDN load balancer.
  • Less cache efficiency
  • Is the Load balancing algorithm suited to your business challenges?