Selling CDN solutions during those days was a totally different story - the vast majority of the clients never heard of such a thing like a CDN, some couldn’t believe it and thought it's snake oil. The job was not to show the KPIs, the job was evangelizing.
In Europe there was not even a handful of vendors present, most solutions didn’t offer a self- service configuration UI, preparation for Proof of Concepts took weeks. It was also the very early days of Edge Compute, companies started to outsource redirects to the CDN, classic one: www.yourhost.com to m.yourhost.com redirect in case you came with a mobile phone - those were not the days of responsive websites.
Today the situation is different: If you are on AWS and you need a CDN, you just click the Cloudfront option. A valid credit card is all you need. And that’s the way several vendors offer their service, no sales guys needed, no Sale Engineers, no written contract on paper.
There are even vendors out there who do not mention the CDN part of their portfolio, they sale full-stack-web security including CDN, Edge Compute including CDN. Often their marketing tells them that CDN became a commodity item, hard to show a USP of their solution.
So CDN is a switch to flip and pay by credit card, right? I object to this.
CDN setup depends on the nature of business
It depends very much on the nature of your business. Let me explain this with two examples.
We have two imaginary companies HappyStream.com and Industrial-vendor.com.
HappyStreams.com is offering videos on demand, their audience is in North America, they are hosted on AWS. The caching requirements are pretty straight forward for them, they only have static content, their region is well defined and connected. If they just turn on Cloudfront with standard settings they will achieve a nice gain in performance and reliability in their user experience.
Industrial-vendor.com is a different story. They produce industrial goods and they just introduced a B2B portal for their clients to order spare parts. Their audience is big factories around the world, so they have clients in South America as well as in Russia, their market with the highest rate of growth is in China.
Each customer has a login, the price gets calculated in real-time in their local backend for each and every user, getting through the middleware and delivered into the website. So the website has static content like the images etc, but parts of it are highly dynamic, only valid for one dedicated client and processed in real-time. Russia, China, dynamic traffic - you think ‚flipping a switch‘ would be enough? Definitely not.
Choosing a vendor turned from commodity to complex pretty fast. And setups like this are more common than you might think because the worldwide delivery of highly dynamic traffic is the day-to-day business for industrial companies, but also airlines and Fintech, and those are just the once that pop up immediately when you think about.
Choosing a CDN provider is a complex process
So the choice of the CDN provider can already be a complex task, let's talk a little bit about the configuration. Configuring a CDN is different than setting up your cache layer on your webserver as the strategy is different.
Let me explain this again with an example.
Let's say you have a website with a live counter of your items on stock / likes / live ticker etc. This contains a very small image as visual representation, similar to the ‚like counter‘ you know from Facebook.
On your webserver, you would set this asset to ‚no-store‘, following the nature of the asset. It can be different for every request, so you will not store it on the Webserver.
How about the CDN? Yes, you will store it. The caching policy on a CDN allows all assets that are (potentially) valid for more than one user as cachable. But it can be different for every request, so how to ensure data consistency between the CDN and the origin (= same asset is shown)?
Easy, you set it to ‚public/cachable‘ with a caching time of 0 seconds.
To explain this let us walk through the cache in chronological order: first requests comes in, the asset is not in the cache, so the CDN picks it up from the origin. The CDN checks the cache settings, its ‚public‘ so it adds it to its cache map. The TTL ( TimeToLive) is 0 seconds.
So the next request comes in from a client, reaches the CDN. The CDN checks if the asset is in the cache-map. Check, its there. But its ‚stale‘ as the TTL ran out. So it sends an IMS (if-modified-since) to check if the Webserver is holding a newer version.
If the Webserver replies with a 304 ( = no newer version) the CDN will deliver the cached asset. So what’s the deal with that, why the big fuzz? The size of a typical Http-header is 700Bytes. Let's pretend that we take a small image with 7KB. That's a factor of 1000. For one request. And the delay will happen in the cable, not on the CPU.
Besides the configuration, there are some political aspects on top of that. How to deliver in China mainland? How to obtain an ICP Registration? How to deliver HTTPS in Russia?
So it quite clear that for a lot of companies the choice of CDN is far away from being commoditized, and won’t be within the next years. You can compare it to buying a CRM system - it's not sexy but it can have a lot of impact on your business.
We at GlobalDots have followed the CDN market worldwide for more than a decade, and we provide our services to some of the largest enterprises on this planet, down to startups and digital natives. If you want to inform yourself on how to deliver your content following your business strategy we are more than happy to help.