The industry’s definition of edge seems simple enough. There are many versions, but the majority read similarly to this one from Accenture:
Edge computing is an emerging computing paradigm which refers to a range of networks and devices at or near the user. Edge is about processing data closer to where it’s being generated, enabling processing at greater speeds and volumes, leading to greater action-led results in real time.
Here’s Amazon‘s, for example. Cloudflare‘s. Ericsson‘s. Fastly‘s. Red Hat‘s. And so on.
All of these definitions differ, but each is consistent that edge status is determined by physical location. From an academic perspective, then, the definition is clean and delineated by a bright line. In reality, however, the line is not quite so bright. There are a variety of issues with the term, but these are the three most pressing.
- The first and most glaring problem with the definition of edge is that locations can be home to an absolutely bewildering array of device types, none of which have much in common with each other. In various briefings in recent quarters, RedMonk has had the following use cases described as edge computing scenarios:
- Agricultural sensor networks
- Autonomous ocean vehicles
- Content Delivery Networks (CDNs)
- Factory floors
- Open ocean oil rigs
- Retail store outlets
- Space exploration probes and Satellites
- Vehicles (Cars, Trucks, etc)
All of these use cases – the space exploration probes in particular – qualify under the above definition of edge computing. But from a practical standpoint, and from a developer’s perspective, what is the actual utility of that term? The technical platforms in these cases have little if anything in common. Their available compute, networking and storage capacities vary widely, as do the applications they support. Is an edge CDN developer capable of writing applications for a probe or a tractor, or vice versa? Are there traditional servers available or merely low power Raspberry Pi-style devices? Is it a traditional use case where geographical proximity happens to be critical, or is it something distinct like the collection of vast streams of telemetry from sensor networks processed and stored in time series databases?
Case in point: when a CDN vendor was recently asked during a briefing whether their customers knew what edge meant, they replied: “Our CDN customers, yes – our definition at least. Our newer customers, no. They usually think it means IoT.”
From the perspective of understanding what the technologies involved are, what they imply and what they require, then, the current edge definition seems to offer little.
-
The second problem with edge is that location of a given asset can be meaningless. Customers of a given AWS application may be close to AWS region US-east-1, but that doesn’t make the application an edge workload. And conversely, when the application is distributed to other availability zones closer to users in other regions, those workloads likewise are indistinguishable from any other typical cloud workload. While geography can be highly relevant, then, it can also have little importance.
-
The third problem with edge is that progress in compute, networking and storage technologies is gradually eroding what used to be very clear boundaries between what technology ran on general purpose platforms and what technology ran at the edge. It wasn’t always possible to run Kubernetes on Raspberry Pi machines, for example. The laws of physics presumably will continue to apply for the foreseeable future, and thus for certain workloads geography will remain a salient factor of the design. But as one time edge platforms continue to evolve towards their general purpose counterparts, the technical distinctions in the technologies used between them will gradually diminish.
Dozens or perhaps hundreds of technology vendors at present have substantial open investments in marketing edge branded products. And to the extent that those marketing investments have both been successful and make sense to their customer base in their particular customer context – CDNs to CDN customers, for example – there’s little immediate need for change. An overnight deprecation of the edge term would almost certainly be problematic, both from a customer confusion standpoint as well as the need to try and educate customers on the fly.
But over the longer term, and particularly for those companies looking to engage more directly with developer populations, rethinking the usage of the term edge is probably necessary. The term clearly has little intrinsic meaning or relevance for practitioners, and is therefore unlikely to be useful in recruitment, retention or requirements definition. In a perfect world, the industry would generate either new, more specific definitions or new subcategories and modifiers of edge that would allow it to better articulate the demands for a given workload. But given that the industry is not known for creative, timely or even useful category descriptors, the next best step might be to gradually phase out or minimize the usage of the term edge in favor of terminology that actually communicates something that can be commonly understood.
Disclosure: AWS, Cloudflare, Fastly and Red Hat are RedMonk customers. Accenture and Ericsson are not currently RedMonk customers.
