Alex Marcham - Understanding Infrastructure Edge Computing

With the internet now firmly established as a constant in the lives of billions of people across the world who rely on it every day for essential services; connectivity to work, family, and friends; and their primary source of entertainment, the same pressures which drove the evolution from the first to the second act of the internet are mounting once more. More users – now including both humans and machines which will both be essential users of the internet – and a range of new use cases that demand real‐time decision making are pushing the current generation of internet infrastructure beyond its original design intentions and capabilities from both a technical and business standpoint.

For these reasons, the 2020s are the first decade of the third act of the internet, a transformation of the network and data centre infrastructure which supports the internet on a global scale towards a new methodology of design, deployment, and operation which heavily relies on infrastructure edge computing to achieve its aims of improving performance, lowering operational costs, and enabling a new class of use cases which are impossible or impractical to support without this continued push towards new levels of network regionalisation and less reliance upon centralised infrastructure.

Now that the three acts of the internet have been established, it is worth considering additional detail in regard to network regionalisation and some early examples of this methodology being applied to the infrastructure of the internet in response to the emergence of the second act itself.

The key trend which the three acts of the internet highlights is the increasing growth of network regionalisation that has occurred over the preceding decades in response to the need to support new use cases, reduce the opportunities for network congestion across the internet, and provide a measurable increase in performance to end users. From a network perspective, which is especially crucial when we are talking about the internet which is itself a global network of networks, generally the shortest path between the source and destination of data in transit is preferable for reasons of both optimal performance and lowest cost, all other characteristics being equal across the network.

This regionalisation of internet infrastructure where key pieces of the network and the data centre move outwards from centralised locations to be deployed on a distributed and regional level is not an accident. As the number of users and their individual usage of the network increased, it became urgent to minimise the length of the network path between the source and destination of traffic.

The Advanced Research Projects Agency Network (ARPANET), first established in 1969 [4], was the precursor to the modern internet. Although other projects existed across the world to develop technologies and standards around such transformative technologies as decentralised networks, packet switching, and resilient routing of data in transit to provide a network with the ability to withstand an attack on its infrastructure, the ARPANET was by far the most influential example.

Although considered to be a leading example of a decentralised network at its inception and during the 1970s and 1980s, by the 1990s the level of centralisation in the architecture of the ARPANET was being strained under the emergence of a large number of new internet users and applications. More regionalisation of internet infrastructure was required to address these challenges, and perhaps the most influential method of achieving this was positioning static content in caches which are placed strategically throughout the network, creating a shorter path between traffic source and destination.

One of the best examples of network regionalisation to solve a specific use case as well as address the needs of network operators is the content delivery network (CDN) work done by Akamai Technologies in the late 1990s [5]. Although compared to today the internet and the world wide web it supports were still in their infancy, with both having gained mainstream acceptance only a few years previously, need for the regionalisation of key infrastructure was already beginning to show as the internet became known for distributing new multimedia content, such as images and early examples of hosted video, which began to strain its underlying networks. If left unaddressed, this strain would have limited the uptake of online services by both businesses and home users and ultimately prevented the adoption of the internet as the go‐to location for businesses, essential services, shopping, and entertainment.

The importance of CDNs and of the practical proof point of the benefits of network regionalisation which they represent cannot be understated. By deploying a large number of distributed content caching nodes throughout the internet, CDNs have drastically reduced the level of centralised load placed on internet infrastructure on a regional, national, and global scale. Today, they are a fact of life for network operators; these static caches are widely deployed in many thousands of instances from a variety of providers such as CacheFly, Cloudflare, and Akamai, who reach agreements with network operators for their deployment and operation within both wired and wireless networks which provide last mile network connectivity. This regionalisation of static content, by moving the CDN nodes to locations closer to their end users, improves the user experience and saves network operators significant sums in the backhaul network capacity which would otherwise be needed to serve the demand for the content were it located farther away in an RNDC.

Where infrastructure edge computing diverges from the historical CDN deployment model is in its ability to support a range of use cases which rely on dense compute resources to operate, such as clusters of central processing units (CPUs), graphics processing units (GPUs), or other resources which enable infrastructure edge computing to provide services beyond the distribution of static content. Many CDN deployments do not require significant compute density, nor are many of the existing telecommunications sites where they are deployed (such as shelters at the bases of cellular towers, cable headend locations, or central office locations) which were originally designed to support low‐density network switching equipment capable of supporting the difficult cooling and power delivery requirements which these dense resources impose. Additionally, in many cases infrastructure edge computing deployments bring additional network infrastructure to provide optimal paths for data transit between last mile networks and edge data centre locations and between edge data centres and RNDCs; typical CDN nodes in contrast will usually be deployed atop existing network operator infrastructure at aggregation points such as cable network headends.

It is worth mentioning here, however, that infrastructure edge computing and the CDN are not at all mutually exclusively concepts. Just as a CDN can operate from various locations across the network today by the deployment of server infrastructure in locations such as cable network headends, they are also able to operate from an IEDC. One or multiple CDNs are then able to use infrastructure edge computing facilities as deployment locations for CDN nodes to replace or augment their existing deployments which use the current infrastructure of the network operator.

Although CDNs in many ways pioneered the deployment methodology of placing numerous content caches throughout the internet to shorten the path between the source and destination of traffic, it is important to understand the distinction between a deployment methodology and a use case. The CDN is a use case which needed a deployment methodology that achieved network regionalisation in order to function. As infrastructure edge computing is deployed, CDNs can also be operated from these locations as well. This is an important point that will be revisited later on the subject of the cloud.