April 20, 2024

From distributed to true edge: 4 edge computing examples

Not all applications are designed for edge computing. In fact, given that current adoption of edge computing is quite limited, it is fair to say that most current applications are not candidates for edge computing.

For example, many types of distributed enterprise installations depend on access to applications ranging from personal productivity tools to inventory management and retail. If these applications were hosted off-site and network connections failed, workers and customers could be isolated, risking losing revenue and control of products and facilities.

Most companies wouldn’t view the above scenario as a cutting-edge computing application, just as they wouldn’t view a desktop PC as a cutting-edge system. Instead, protective local processing falls into the category of distributed computing. Treating it as a cutting-edge application is likely to increase costs, development complexity, and stress on product choices.

So what does edge computing really exemplify and where does it fit in the enterprise? As real-world use cases for edge computing emerge, more advanced examples highlight not only edge cloud-as-a-service offerings but also the shift from distributed computing to true edge.

4 examples of edge computing

The best way to understand where edge computing comes into play is to choose some realistic examples that reflect the evolution of edge computing applications.

1. Point of sale

At first glance, point of sale appears to fall within the boundaries of protective local processing. However, the point of sale has a subtle difference: application latency can affect worker or customer behavior.

When a cashier or customer scans barcodes on products, they expect positive feedback, usually in an audio tone, a description of the item on a screen, or both. This remote site activity has potential latency limitations, but they are less stringent than those found in automated manufacturing applications.

Therefore, point of sale is a combination of distributed and edge computing. Although the use of remotely located computing resources for applications could introduce latency issues due to connection or resource congestion in the data center, on-premises applications rarely require special techniques to further manage latency. Still, developers should carefully check scan response time limitations, as missed scans lead to retail losses.

2. Storage

This example of edge computing lies on the other side of the distributed edge divide: storage applications that involve a combination of human and automated asset movement and accounting.

In these applications, trucks arrive and leave a facility, and workers load and unload goods from these trucks. Goods are removed or added to inventory and linked or unlinked to trucking inventory. The products themselves are packaged and labeled with barcodes, and as they move on or off shelves or on conveyor belts, scanners record their barcodes to help create a model that shows the movement of the products. products.

The pace of activity can be high and, because movement must be coordinated between humans and automated facilities, it is not possible to stop and recover lost information: the system cannot keep up. In many cases, automated package handling diverts goods onto new paths as they pass, and any delay can result in moving the wrong package.

Traditional local inventory processes work here, but also automated processes. Additionally, latency management is very important. This makes storage an edge computing application that is more likely to be supported by local controller and server resources. Consequently, developers should consider it an integrated control application.

3. Versatile transportation

The example of edge computing in transportation is valid for road, rail, air and maritime companies. Versatile transport exposes problems that could turn a local edge hosting application into an edge services application.

In transportation applications, both content and transportation are important. Barcodes, QR codes and RFID can identify objects of any type as sensors read them during loading, unloading and even movement. Telemetry devices that include sensors can provide other details, such as temperature and GPS location.

The normal application structure for reading these metrics is to collect data at many points and then send it inward – a perfect model of an edge/cloud or edge/data center application. Because transportation applications naturally obtain sensor data in batches at key points, latency management is critical to ensuring that data is not lost and that issues are analyzed quickly.

Today, a number of facility-bound devices support applications in this use case, but there is increased use of mobile services (including 5G) and interest in edge hosting services. The very batch nature of sensor reporting means that transport applications tend to be sporadic in terms of usage, making them ideal for support through edge hosting.

4. The smart city

In a way, the final example is the sum of the rest. The smart city could be a city, but it could also be a campus, a stadium, or even a battlefield. What characterizes the smart city is a combination of variety and unpredictability, coupled with the fact that, in many cases, property and lives could be at risk if something goes wrong.

The smart city illustrates that the world is big. Inherently, handling it at the application level requires decomposing it into interdependent systems. Each of these remains a real-time component of the larger picture, so each processes its local events and contributes events to broader systems in succession. The event-centric nature of operations at each level means low-latency local processing, and the synchrony of the entire system depends on the rapid and consistent movement of events.

Some elements of the smart city could be other peripheral use cases seen as distributed computing if considered on their own. Even protective local processing, in a smart city context, could require real-time integration with a system that alerts shoppers to deals as they pass by a store. This would require understanding both pricing and inventory. The smarter the city (or a city-like set of facilities), the more real-time and edge-centric the system elements of that set should be.

Tom Nolle is founder and principal analyst at Andover Intel, a consulting and analytics firm that analyzes evolving technologies and applications first from the perspective of the buyer and their needs. By experience, Nolle is a programmer, software architect, and manager of software and network products, and has provided technology consulting and analysis services for decades.

Leave a Reply

Your email address will not be published. Required fields are marked *