For nearly 20 years, use of Content Delivery Networks (CDNs) has been a smart way to deliver web traffic. CDNs promise faster, more secure and more scalable web applications. However, modern software development practices and the definition of networks and infrastructure using a software-centric approach are making legacy CDNs increasingly less relevant. “Software is eating the world” and CDNs have forgotten to come to the table.
The problem is that the CDN network and software structure is the product of a waterfall development world. CDNs can neither embrace modern software development speeds themselves nor support applications which use modern software development practices.
CDN Software Can’t Change Fast Enough
Aside from DNS and routing technologies CDNs consist of two key components; 1. Computers distributed around the Internet (Points of Presence or PoPs) which run the CDN software 2. CDN Software - also known as Reverse Proxy Software (Used for Caching, Web Application Firewall, Bot Blocking, Image Optimization, WAN Optimization, Front End Optimization, API Authentication etc)
Akamai was the first the build out a network using DNS, distributed computers and reverse proxy software. As was the custom at the time, they coupled the software tightly to the network and compute. Following the same network build approach of Akamai, the reverse proxy software has been so tightly coupled to the network infrastructure by all CDNs that making fundamental changes to the software itself is proving complex for CDNs.
Unfortunately for CDNs, advancements in reverse proxy software are moving fast. Dramatic new approaches to handling web traffic for the purposes of improving security, scalability and performance are being launched more frequently than ever before. CDNs cannot move quickly enough to take advantage of these software developments.
By way of example;
- Level 3 has taken over three years to migrate from its Squid based caching proxy to Nginx. We believe this project may still be ongoing.
- Fastly’s caching reverse proxy is still based on Varnish Cache 2.1 whereas Varnish Cache itself has now moved on to version 5.
- The Modsecurity based firewalls being run by the likes of Akamai and Cloudflare are being left way behind in features, functionality and ease of use by the newer “learning” WAF products like Threat X and Signal Sciences.
- Newer and smarter Bot Blocking and Anti Scraping proxies like Perimeter X and Distil Networks have hit the market leaving the Bot Blocking capabilities of the CDNs behind.
- Fastly have been promising the release of a WAF for years but have not yet delivered.
The only thing we can be sure of with respect to proxy software for the delivery and security of web traffic is that there will be more coming onto the market and that software provided by niche players and specialists will become significantly smarter than what CDNs currently provide.
Due to the old school architectural constraints, CDNs cannot move to deploy these newer reverse proxy technologies. Their features and functionality will be overrun.
A software-based approach provides customer level flexibility on which software is run for each customer and even what version of software is run per customer. Upgrade paths can become independently driven on a per customer basis; as compared with an upgrade of the amorphous mass of proprietary proxy software legacy CDNs run. What’s more, customers of a software-defined proxy network can become future proofed against changes and upgrades to proxy software. When new software arrives they can test and deploy when ready.
CDNs Were Not Built to Support Modern Agile Developers
CDNs will not keep pace with the agile movement. As Continuous Delivery and Continuous Integration are more widely adopted, it is becoming more challenging for CDNs to keep in sync with the application being delivered, meaning CDNs are becoming generally less effective.
As we have noted in previous posts, CDNs live only in production. CDN proxy software, and hence the impact it has on the application it serves, remains totally separate from the core application development process. This breaks the fundamental principles of agile software development.
Again, due to the old school architectural constraints (relating to the locking up of the proprietary proxy software with the network) CDNs cannot be pulled into the software development lifecycles for modern web application development.
More sophisticated customers are looking for CDN integration with their development lifecycle right now. Take for example the following hacks that have been created to deal with the lack of developer tools supporting agile teams in today’s CDNs:
- From REA Group to statistically test Akamai config in production or staging, well after development cycles: https://github.com/realestate-com-au/akamai-rspec/
- Fastly emulator built by Reddit: https://github.com/reddit/varnish-fastly
Others quietly (or sometimes not so quietly) suffer the consequences of missing out on the ability to modify, test and deploy the CDN software in their development environments. For example, we wrote about a Steam Store incident in which the website needed to rapidly update caching configuration after a DDoS attack. We have also heard many examples where customers have turned off the Web Application Firewall or caching features of a CDN for which they have paid simply because they cannot run a sensible development and test cycle against these valuable features and hence, cannot make them work safely with their application.
A Software-Driven, Agile Content Delivery Solution
Reverse proxy software can provide a vast range of tremendous benefits for web application performance, availability and security. The challenges of the modern Internet for web content providers are increasing. It’s harder now for content providers to deliver larger amounts of more complicated web content to a wider and more complicated range of devices with more demanding consumers of that content. Against these challenges, reverse proxies should play an even larger part of the content delivery solution.
We need a new, software-driven approach to providing web engineers with access to and control over reverse proxy software; regardless of whether the software is running at the origin or in a CDN. Engineers should be able to safely exploit the tremendous benefits of reverse proxies. Engineers should not feel locked into any one proxy software stack at any one time but be able to pick and choose the tools that work best for their website.
By decoupling proxy software from the networks and taking a software-driven approach to configuration, management and deployment of reverse proxies, section.io’s Content Delivery Grid is the future of a web application delivery platform. The Content Delivery Grid gives developers full control over reverse proxy configuration, regularly adds reverse proxies to its offerings, and provides a testing environment so changes can be tested locally. To learn more about how section.io’s Content Delivery Grid can work for your website, please contact a member of our team today.