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.
Figure 2.5 Application with access to infrastructure edge computing resources.
In many cases, the ideal set of resources does not exist in only one of these three locations. To make the best use of this gradient of resources from device to national data centre, an application and its operator should seek to optimise which functions are performed using which set of resources and take into account the individual characteristics of each of these sets. This is a complex issue which will be explored further in this book; do not worry too much about the minutiae of this right now.
As can be seen from this example, just as the use of the RNDC expanded the capabilities of applications which previously could rely on the resources available to them only on a user’s device, the IEDC adds an additional layer of resources which augments the capabilities of both the device and the RNDC. This gradient of resources which spans from the device in a user’s hands to an IEDC all the way to a national data centre which may be thousands of miles away, is the foundation of the next‐generation internet, enabling new valuable classes of applications and use cases to be practical.
2.7 Summary
This chapter formed the basis of an introduction to edge computing, describing the key terminology and many of the core concepts which are driving the design, deployment, and operation specifically of infrastructure edge computing but also with coverage of device edge computing. The terminology and concepts described in this chapter will be used frequently throughout the rest of this book, so it may be useful to refer back to the key points of this chapter at a later date to refresh your memory.
In the next chapter, we will explore the foundations of network technology to give full context to the impact of infrastructure edge computing on these concepts and to then establish a clear baseline on which to build our understanding of how tomorrow’s networks will differ from those we see today.
References
1 1 The Linux Foundation. Open glossary of edge computing [Internet]. 2019 [cited 2020 Sep 30]. Available from: https://www.lfedge.org/openglossary
2 2 The Linux Foundation. State of the edge [Internet]. 2019 [cited 2020 Sep 30]. Available from: https://www.stateoftheedge.com
3 3 The Linux Foundation. LF Edge [Internet]. 2020 [cited 2020 Sep 30]. Available from: https://www.lfedge.org
4 4 DARPA (Defense Advanced Research Projects Agency). ARPANET [Internet]. 2020 [cited 2020 Sep 30]. Available from: https://www.darpa.mil/about‐us/timeline/arpanet
5 5 Akamai Technologies. Company history [Internet]. 2020 [cited 2020 Sep 30]. Available from: https://www.akamai.com/us/en/about/company‐history.jsp
3
