Alex Marcham - Understanding Infrastructure Edge Computing

Now that we have established the terminology and some of the history behind the concept of edge computing, we can delve deeper into the specific factors which make this technology appealing for a wide range of use cases and users. We will return to many of these factors throughout this book, but this section will establish these factors and the basic reasoning behind their importance at the edge.

The time required for a single bit, packet, or frame of data to be successfully transmitted between its source and destination can be measured in extreme detail by a variety of mechanisms. Between the ports on a single Ethernet switch, nanosecond scale latencies can be achieved, though they are more frequently measured in microseconds. Between devices, microsecond or millisecond scale latencies are observed, and across a large‐scale WAN, such as an access or last mile access network, hundreds of milliseconds of latency are commonly experienced, especially when the traffic destination is in a remote location relative to the source of the data, as is the case when a user located on the device edge seeks to use an application being hosted in a remote centralised data centre facility.

Latency is typically considered to be the primary performance benefit which edge computing and particularly infrastructure edge computing can provide to its end users, although other performance advantages exist such as the ability to avoid current hotspots of network congestion by reducing the length of the network path between a user and the data centre running their application of choice.

Beyond a certain point of acceptability, where the required data rate is provided by the network to the application for it to function as intended, increasing the bandwidth and therefore the maximum data rate that is provided to a user or application on the network for a real‐time use case does not measurably increase their quality of experience (QoE). The primary drivers of increased user QoE are then latency, measured at its maximum, minimum, and average over a period of time, and the ability of the system to provide as close to deterministic performance as possible by avoiding congestion.

The physical distance between a user and the data centre providing their application or service is not the only factor which influences latency from the network perspective. The network topology that exists between the end user and the data centre is also of significant concern; to achieve the lowest latency, as direct a connection as possible is preferable rather than relying on many circuitous routes which introduces additional delay in data transport. In extreme cases, data may be sent away from its intended destination before taking a hairpin turn back on a return path to get there. This is referred to as a traffic trombone, with the path which the data takes resembling the shape of the instrument.

Data gravity refers to the challenge of moving large amounts of data. To move data from where it was collected or generated to a location where it can be processed or stored requires energy which can be expressed both in terms of network and processing resources as well as financial cost, which can be prohibitive when dealing with a large amount of data that has real‐time processing needs.

Additionally, many individual pieces of data that are collected or generated can, once processed, be considered noise as they do not significantly contribute to the insight which can be generated by the analysis of the data. Before processing occurs, however, it is difficult to know which pieces of data can be discarded as insignificant, and an individual device may not have all of the contextual information or the analytic processing power available to accurately make this judgement. This makes the use of infrastructure edge computing key as this processing can occur comparatively close to the source of the data before the resulting insight is sent back to a regional data centre for long‐term data storage.

Many pieces of data have a window of time in which they are most useful. If within that time period they cannot be processed and used to extract an actionable insight, the value of that data decreases exponentially. Examples of this type of data include many real‐time applications; for example, in the scenario of an industrial robotics control system, instructing the system to perform an action such as orienting a robotic arm in a certain position to catch a piece of falling material is of limited use if the command reaches the arm too late to perform that action in a safe manner before the material falls.

Data velocity is the name given to this concept. If data for real‐time applications can be processed and used to extract insight within the shortest possible span of time since its creation or collection, that data and the resulting insight are able to provide their highest possible value to their end user. This processing must occur at a point of aggregation in terms of both network topology and compute resources, such that the resulting data analysis has the full context of relevant events and the power to perform the analysis at an acceptable rate for the application and its users to prevent any issues.

Particularly with emerging use cases such as distributed artificial intelligence (AI), the cost of transporting data from the device edge locations where it is generated to a data centre location where it can be processed in real time will present a growing challenge. This is not only a technical consideration where network operators must appropriately provision upstream bandwidth in the access and midhaul layers of the network, but there is also a significant operational expenditure (OPEX) and capital expenditure (CAPEX) burden on the network operator associated with overprovisioning long‐haul network connectivity.

Infrastructure edge computing aims to address this challenge by moving the locations at which large amounts of data can undergo complex processing, for example, by distributed AI inferencing, to a set of locations which are positioned closer to the sources of this data than with today’s centralised data centres. The shorter the distance over which the bulk of data must be transmitted, the lower the data transport cost can be for the network operator which allows any use case reliant on moving such large volumes of data to be more economical and thus more practical to deploy and operate.

The locality of a system describes both the physical and logical distances between key components of the system. In the context of infrastructure edge computing, the system we are most concerned with spans from a user located on the device edge to an application operating from an edge data centre at the infrastructure edge, a facility which itself is then connected to a regional data centre.

Locality is an important concept in system design. In many ways it is the summation of all of the previously described issues in this section; by addressing all of them, locality allows infrastructure edge computing to enable a new class of use case which generates large amounts of data and needs that data to be processed in a complex fashion in real time. This is the true driving factor of why the infrastructure edge computing model is needed; new use cases in addition to useful augmentations of existing use cases require the capabilities which it offers, and these use cases are valuable enough to make the design, deployment, and operation of infrastructure edge computing itself worthwhile.