The future of Content Delivery
The future of Content Delivery

By Victor Gartvich (LinkedIn)

TD;DR – in 5-10 years the content delivery will be polarized into two types of technology: 1) “bytes moving” solid and simple CDNs, and 2) “bytes generating” CDNs which will bring customer applications to the edge, very close to end users. All current CDNs will transform (or stay) into one of the two categories.

What we have now?

The CDN space today is characterized by two different types of CDNs, “bytes-moving” and “bytes-modifying.”  Bytes-moving CDNs are essentially the same kind of CDN as the commercial service pioneered in 1996.  Overtime CDNs have somewhat evolved into a complex environment for content acceleration dealing with both static and dynamic content.  All CDNs offer some form of bytes-moving, after all that is their history and several now offer bytes-modification in the form of Front-End Optimization (FEO).  FEO is service which is generally seen as a way to “stream” content to a browser by modifying content dynamically based on end-user information.  FEO products and services commonly have different instructions for browsers on what content to request or how to load content to improve the user’s experience, but they stop far short of true manipulation of content as the really create a complex set of cache directives.  As more content comes from 3rd parties or the content calls become buried inside of javascripts, the treatments are becoming more risky and more prone to breaking pages.  Another area which causes problems for FEO or bytes-modifying CDNs is when many different versions of pages are being served or there is a high variation of content.  FEO uses a “machine learning” process to understand what content is on a page and if it is constantly changing or becoming unpredictable, the value of machine learning declines rapidly.

The goal of any CDN or service is to assist in the building of better and faster websites and mobile Internet applications; however, website performance is not improving as fast as users expect. We all have faster Internet connections, high-speed Wi-Fi, more powerful computers/laptops/smartphones, but the consensus is that the Internet is not actually becoming faster. Websites are becoming more functional, interactive, dynamic, and complex relying more and more on devices to process the display layer. This creates a lot of variation in what users experience and while a site may work pretty fast and as expected, frequently sites suddenly become slow or break. The site can simply have missing images or completely malformed pages and you never know when it will happen or what the level of degradation will be.

The reason for some of the instability is that modern websites are built using many complex components that can be distributed and rely on dozens of different providers or technologies, which web business owners no longer have control over.  The cloud has simplified the process of moving website backends, databases, browser libraries, references to other websites like Facebook/LinkedIn, into the commonplace of web development versus the web of the 90’s and 2000’s, which is when CDNs were originally designed.  The increased dependency on external APIs and third-party links have further complicated matters. The end result, no matter which of these areas a development team wishes to focus is that web developers have less control over their applications, and need to constantly monitor-modify-test-push their code to adjust to changing environments.

5-10 years ago the benefits of CDN deployment for a simple/static website were pretty obvious: web origin is generating bytes, CDN is taking the bytes to the edge and serving to end user browsers and this distribution reduced the latency to the end-user.  A browser’s page complete time was a good metric of web performance, and the majority of websites indeed harnessed a benefit by providing better end user experience by implementing caching CDN service.

As the internet evolved it has created a situation where CDN benefits are actually masked by complex website architecture, page load times being heavily influenced by third party content, and end-user equipment making performance dependent on CPU/memory-consuming JS applications running on busy end user devices, slow database backends hosted in cheap and unpredicted cloud environment, underperforming or broken third-party web links served by partners, etc. In the current variety of web consuming environments web publishers have to make a lot of performance and functionality assumptions about target devices, and the assumptions are not always satisfied in the real world.

To further complicate matters, mobile users are now approximately 40% of a typical site’s users, which has increased the visibility and need for acceleration specifically for the challenges of mobile users. Wireless Internet is different from wired network, and many of classic CDN approaches are less efficient in cellular networks with high latency, bloated buffers and Performance Enhancing Proxies (PEPs) managed by mobile providers.

What’s the Best Way to Address these Challenges?

Above I asserted that there are two types of CDN services:

  1. CDNs which are simply bytes-moving where the CDN is simply doing its best to move bytes faster from web origin servers to end users by shortening the latency of the last mile. Fastly is a good example of such company.
  2. CDNs which are bytes-modifying delivered content by applying different content optimization and streaming strategies, through either reduction the amount of transferred data or changing the way how web data/code is used by web browsers. Instart Logic is one example of a company from this domain.

Bytes-moving CDNs are limited in the amount of overall performance simply because their approach to performance is to replicate content to as many servers as is needed to reduce latency in the last mile.  This is effective to a point, but if the performance problems are inherent in the last mile, then a bytes-moving CDN can not have a huge effect on performance end to end.  This is what lead to the creation of bytes-modifying services and technologies.

Bytes-modifying CDNs stepped in to take over where byte-movers stopped and that is to modify content so that users get content that is more optimized for their given platform, CPU, network, or whatever information can be acted upon from the end-user’s agent, which will provide a better performance result.  This evolution of CDN essentially takes a site’s content, factors of about the end-user like platform or browser and send across content in a specialized way for that user to receive the best possible performance given the user agent data and a list of instructions to follow.  These solutions are helpful in compression or removing whitespace in the Javascript or CSS, but rely on the power of the browser to actually carry out the instructions.  In a wired world, this is not an issue because power and performance is rarely the weak link; however, as mobile devices make up over 40% of most web traffic and higher when it comes to e-commerce this technology will place significant burden on user devices.  The result is really hard to test for.

Another limitation of bytes-modifiers is the amount of safe data/code modifications you can perform on the fly in a complex web application, which in many cases can rapidly cause broken pages as web content changes dynamically. According to the trend of complexity,  it is clear that web applications will be skyrocketing in their complexity over the following years, and this will leave less and less room for safe data/code alternations.

What Does the Next Generation Look Like?

The next Generation CDNs will take on a whole new look.  These CDN’s will be considered “Bytes-Generating” CDNs, which is to say they will execute application code and derivative databases inside of caching networks and execute calls to 3rd party data stores to create custom content for end-users inside of the cache, rather than at the origin. This won’t replace all of a site’s logic, but the most mundane functions will become resident in the end points where users have to connect today in order to simply obtain cached content. The implication of bytes-generating CDNs cannot be understated.

For performance and customer specialization the edge is the best place to create content for users. A developer will be able to integrate API service calls into the edge and with some simple or basic Lua, Node.js or VLC the edge can generate content.  Furthermore, bytes-generating CDNs will find it necessary to deploy databases on their edge servers to assist in moving the ability to generate content and remove 3rd party restrictions or latency in fetching details to customize.  When you are generating content on the CDN edge, you can reduce the size of your origin infrastructure, reduce cost of bandwidth, and increase the security overall of your site by blocking bots or bad actors before they can reach your origin.

As this evolution of CDN service continues toward the path of content generation at the edge, CDNs will begin to look more like content-as-a-service (CaaS).  The next great evolution of the web is going to be a fully personalized experience that takes into consideration a user, their connection, platform, interest, and so forth to properly generate the experience that the user is truly interested in, but it can only be realized if content can truly be generated at the edge and with a performance, which meets users expectations.  To get here, developers will need to control and manage their users expectations and the services creating content to meet the expectation and while there is still a lot of potential for bytes-moving CDNs; over time, companies not generating content closer to the end-user in a way that is customized for the client and device combination, performance will continue to suffer, and user frustration will quicken resulting in lower revenue and lower satisfaction.  The time has come to evolve.