Alex Marcham - Understanding Infrastructure Edge Computing

With an understanding of the basic terminology and history behind infrastructure edge computing, as well as the primary factors, beyond specific use cases, which are driving its design, deployment, and adoption, we can explore an example of how edge computing operates in practice. This example will describe how each of the primary factors are addressed by infrastructure edge computing, as well as how interoperation can occur between the device edge, infrastructure edge, and RNDCs to make a useful gradient of compute, storage, and network resources from end to end.

To begin, let’s explore the operation of an application which needs only device edge computing to function. In this scenario, all of the compute and storage resources required are provided by a local device, in this example, a smartphone. Any data that is required is being generated locally and is not obtained from a remote location as the application operates, unlike if the application were reliant on the cloud. The application is entirely self‐contained at the user’s device, and so operates as follows in Figure 2.3:

In this case, the application is limited by the capabilities of the device itself. All of the resources that the application requires, such as to process data, display a complex 3D rendering to the user, or store data which results from the user’s actions, must all be present on the local device and also available to the application. If this is not met, the application will either fail or its operation will be degraded, leaving the user with a suboptimal experience. The use of only device resources requires devices to be powerful enough to provide everything that is required by any application which the user may wish to use, which is especially detrimental to mobile devices which must be battery powered and so not capable of supporting dense amounts of compute and storage resources as may be needed.

The extent to which this is a drawback varies depending on the type of application and on the type of device in question. A lightweight application may operate exactly as intended on a device alone, whereas an application which introduces more of a mismatch between the capabilities of the device and the requirements of the application, such as performing high‐resolution real‐time computer vision for facial recognition on a battery‐powered mobile device, may either not operate at all or compromise the user experience, for example, by providing greatly reduced performance or poor battery life, to the extent that the application is unable to fulfil the needs of the user and so fails.

Figure 2.3 Self‐contained application operating on device.

Next, we will add an RNDC to the same application. This addition opens up significant new functionality and opportunities for the application but also comes with its own set of drawbacks. The user’s device is connected to the remote data centre using internet connectivity. The device connects to a last mile network, in this example a fourth generation (4G) LTE cellular network, and uses this connection to send and receive data to an application instance which is operating in the remote data centre. This application instance is now using a combination of device resources and data centre resources, most likely by utilising a public or private cloud service. Note, however, that the cloud is a not a physical place in and of itself; it is a logical service which uses physical data centre locations and the resources present inside them to provide those services to its users. This distinction will become increasingly important throughout this book as the infrastructure used by the cloud includes not only RNDCs but also IEDCs (see Figure 2.4).

In this case, the application is able to call on not just the local resources which are available at the device but also remote resources located within the remote data centre in order to perform its functions. These resources are primarily processing power and data storage, both of which are capable of adding additional capabilities and levels of performance to the application which the device alone is unable to support, and access to them often greatly enriches the user experience.

One difficulty with this case is that the RNDC is typically located a large distance away from the end user and their device. This imposes two challenges on the application: When the transmission of large amounts of data is required, that data is sent using long‐distance network connectivity which, if all other characteristics of the network are equal, is costlier and is prone to introducing more opportunities for network congestion than the network connectivity which would be required for a shorter distance between a device and its serving data centre. The other challenge is latency: Should a real‐time element of the application be required which is not possible or practical to support using the local resources of the device, then the data centre must be physically located close enough to the device for the network connectivity between them to provide acceptable latency so that the user experience will not be degraded and the application will be able to function as intended. This is often challenging as a user may be many hundreds or thousands of miles away from the data centre, which is supporting their application, exacerbating these issues.

Figure 2.4 Application with access to remote data centre resources.

Finally, let’s examine what this same use case looks like with the introduction of infrastructure edge computing. A single IEDC has been added to our previous topology, with its location being in between the user’s device and the RNDC. In addition the IEDC is interconnected with the last mile network which the device is connected to, and is connected back to the RNDC. These two elements are crucial to ensure optimal network connectivity, and they will be explored further in the next chapter.

In this case, the application has access to three sets of resources in increasing degrees of the total potential resources available: the device itself, the IEDC, and the RNDC. As can be seen in Figure 2.5, these resources are physically located in a gradient from the device in the user’s hand to a national data centre which may be thousands of miles away. The IEDC is optimally located no more than 15 miles away from the user to minimise latency while still being able to support the dense resources that are required by the application; in this way, the IEDC is able to support the needs of the application in the same way as an RNDC but from a physical location that is much closer to the end user. This blend of characteristics shows the power of the optimal infrastructure edge computing deployment, where an edge data centre can provide a low latency comparable to the device itself, with the back‐end muscle of the larger scale data centre.

Although the IEDC is physically a fraction of the size of the RNDC, its resources are capable of providing similar capabilities for the users that are within its area of operations. This is a balance which is achieved by deploying many IEDCs in a given area, such as across a city, and determining the user population that surrounds each one of those facilities; this can be achieved by drawing a 15‐mile radius around each facility to maintain low latency. Should additional resources be required over time, additional IEDCs can be deployed, and the user population is then segmented again to prevent individual data centres from becoming heavily congested. This deployment and operation methodology allows infrastructure edge computing to scale over time beyond an initial deployment.