CDNs as Money Savers
Many people think of the CDN as solving technical problems such as scaling, lowering latency, and increasing or ensuring availability.
The fact is that the first CDNs emerged in order to save money. It was reasoned that by having a “local” “forward” proxy server, the international/ long-distance connectivity requirements could be reduced. Forward proxy servers were hugely popular in enterprise networks during the mid- to late 1990s, and indeed on through most of the following decade. They served two purposes. First they reduced the amount of capacity a branch network needed to be able to provide the users on site with broad access to the data that the central head office wanted to disseminate to the branch offices. In the simplest model the users in the branch office would make a request of the company's webserver, and the proxy server would check to see if the data being searched was already cached locally, and if so, it would serve the user with that content without having to use the IP connection back to the head office. At scale this meant that an office with 100 users might see significant percentages of the calls to the company web service served locally, and this would directly reflect on the size of the expensive leased line IP connection that the branch office required.
The other major purpose of this type of proxy server is to act as a security gateway out of the office, ensuring that company employees are surfing websites they are supposed to, and so on.
There are also reverse proxy servers; these help core network services scale. Ultimately both forward and reverse proxy servers perform the same role: they act as a point of service for downstream end users, and they reduce the traffic “pressure” on the core.
Speedera, and then Akamai, managed to win the responsibility of delivering some large software updates for major software vendors, and positioned themselves to deliver proxy caches in many locations. This meant that they could achieve scales of delivery to end users, and yet offer cost savings to their clients who effectively put these early CDNs into the role of lowering their peering and Interconnection costs.
So a thousand users in the UK accessing CNN.com no longer needed their ISP and CNN.com to ensure that the pipes were large enough to handle their every request over the Atlantic. Instead, the CDN installed a proxy server in the UK, to which all the users connected through the ISP and the ISPs domestic connection to the CDN, and the CDN has a very small transatlantic connection over which just the initial update to the website was copied, once, costing the CDN very little, while effectively giving the end users a transparent and slightly faster (less latency) service.
At first the early CDNs had huge margins of cost to offer to save their clients: CNN itself would pay the CDN to handle delivery rather than increasing its core webserver/reverse proxy cluster size and its connectivity. This represented a significant scaling cost reduction to content publishers.
Second, CND reduced the subscriber ISP's need to keep scaling direct peer- ings and interconnects with expensive transatlantic routes, instead connecting locally in the UK on a low-cost co-located route to the local CDN proxy server. While CDNs' relationships and deal architecture with ISPs vary hugely to this day, they remained competitive with the alternative cost of the ISP's direct connectivity to publishers' source networks simply through an economy of scale. Further, even where the cost differential would be negligible, the CDNs developed a secondary value proposition as a way to maintain price in the hugely commoditized market it has become today; today, they focus metrics such as low latency for the timely delivery of content, and latterly they deal in more and more “split-hair” differentials such as jitter/time to first byte and myriad other metrics that, to be honest, help sales more than they really help the technical delivery in any practical terms as far as operations or the good enough expectations of the audiences.