Birth of the Term “CDN”
Nearly 20 years ago, Akamai launched the first content delivery network. They rocked the web world by distributing reverse proxy servers globally into a number of Points of Presence (PoPs) to act as content caches and ran a layer of DNS over the top to select the closest PoP to the user.
The impact for websites at the time was immediate. All of a sudden the images which were being served over and over again from the origin servers were being served from Akamai’s reverse proxy servers. This meant fewer choke points at the origin network and improvement in delivery speed into the browser due to lower latency.
Content was being delivered from the Akamai network of reverse proxy servers. And the CDN name was born.
We understand from industry chit chat that Akamai started their network with Squid. Squid is an open source reverse proxy server which functions as a cache for static objects such as images. Squid was doing not much else at the time other than caching and subsequently serving content (largely images) to browsers. “CDN” made sense as a name for a network of reverse proxy servers performing this function.
Fast forward 20 years and CDNs can now include a wide range of reverse proxy servers performing a range of functions. Some examples of reverse proxy servers now deployed by “CDNs” include:
- Nginx – open source server which can be run as a reverse proxy. Performing functions including caching, rewriting (e.g. running LUA or web application firewall. Cloudflare for example use Nginx extensively in their network.
- ModSecurity – An open source Web Application Firewall which can detect and / or block a range of requests based on parsing the request looking for a match to certain content. Cloudflare and Akamai both based their security products on older versions of this Reverse Proxy.
- Varnish Cache – An Open Source HTTP accelerator which caches content (including the whole page), and due to its programmability can be driven hard to perform a wide variety of functions in addition to caching (e.g. Load balancer style activity). Fastly built their CDN based on older versions of Varnish Cache. Max CDN also use Varnish Cache for parts of their CDN.
- Google’s PageSpeed Module – Built and maintained by Google, this open source reverse proxy can perform a very wide range of Front End Optimisation activities to a webpage including resizing images, rewriting image types, engaging image lazy loading, prioritising critical CSS etc. Verizon built this into their CDN and companies such as Yottaa built their networks on using similar reverse proxies.
The above are just a few of the many reverse proxies which can now be offered to users in a distributed network. By doing so, website owners and developers can take advantage of the awesome features these reverse proxies offer, without needing to worry about deployment, patching scalability etc.
“CDN” Only Covers 10% of Modern CDNs Functionality
What is apparent from the above is that CDN is no longer a relevant term to apply to networks running all these proxies.
A modern network in front of a web server should no longer just be delivering static content. Such a network would only be making use of maybe 10% of the features and benefits of a distributed reverse proxy network.
As discussed above, reverse proxies running in distributed networks can do many things including:
- Delivering content
- Blocking inbound requests,
- Modifying and improving whole pages and content
- Re rerouting requests
- Reporting and alerting on the status of the requests and the outbound content
- Selectively caching and serving entire webpages
- Serving alternate content based on rulesets
- Challenging spurious requests, etc
These activities go far beyond Content Delivery.
Unfortunately, even though the legacy CDNs have rolled out additional reverse proxies into their networks, these powerful features are often ignored or seriously underutilised because they are just “too hard” to set up and manage on those legacy CDNs. The locked down, production-only nature of legacy CDNs and poor visibility for developers and operations engineers makes their functionality, (beyond the basic static object caching) difficult and often risky to leverage.
We Need a New Name for New Functionality
Things have moved a long way in the last 20 years, but if you use a CDN only for static object caching, then CDN is what you are using. If you are looking for more performance, security and scalability from your distributed reverse proxy network, then let’s find a new name. You are going beyond the old school CDN.
The team at Instart Logic coined a term to describe their network of reverse proxies- Application Delivery Network. I’m not sure this goes far enough as it still discusses a one way, limited conversation between browser and the network.
At Section we publish a range of open source reverse proxies on our network. We don’t hide them in a “block box” or protect them with patents. As such, we can bring many reverse proxies to our users so they have a choice of which reverse proxies they want to run on our network. For example, at Section you can choose between Varnish Cache 3 or 4. We also provide our users with the tools to drive the proxies effectively. Developers can finally unlock the full potential of these reverse proxy servers in a safe and efficient manner.
Section is a reverse proxy management platform which can be deployed in either a distributed fashion (like a CDN) or inside a firewall as an Application Delivery Controller (or both). It’s the first software defined reverse proxy management platform.
So, how do we describe all that with a three letter acronym?