Ah, words… Simple audio utterances that contain meaning. Well, except when they don’t. Or when each of us parses a different meaning out of a given collection of phonemes, making even morphemes morph.

In our world of technology, in particular, we deal with inordinately complex concepts, and we have to find shorthand ways of referring to them, or else we’d forever be locked up with convoluted phrases like, “a single binary unit of information” instead of “bit.” And, in most cases, for purposes of communicating in the English language, we borrow from the vast English lexicon (or occasionally from other languages, but English has a rather large vocabulary from which to choose). We take words that mean some specific mundane thing – like “bit” – and leverage them for some technical concept that evokes the simple meaning of the word.

So, for example, when describing the overall architecture of the Internet of Things, we have several large-scale features that need names. We have “things” and we have the “cloud.” Drilling deeper, we have a big, giant network connecting it all together. And there are different places in that network that merit their own words. The middle of the network, where traffic volumes are enormous, is the “core.” And the IoT devices themselves are way out at the “edge” of the network.
Or are they?

We also suffer from some level of myopia, restricting the context of those words to some limited scope, outside of which the word choice no longer makes sense. And “edge” is one of those words.

OK… Exactly Where Are We Going with This?

I should probably pause to make this relevant. No, this isn’t a paean to the variety and flexibility of the English (or any other) lexicon. No, it’s stimulated out of true confusion on my part – until I received a contextual straightening out.

The topic at hand was a project named EdgeX, an effort put forth by the Linux Foundation. I say, “was,” because my confusion was past tense. EdgeX is present tense. Just to be clear. They describe themselves as, “The Open Interop Platform for the IoT Edge.” Their focus is the Industrial IoT. Sounds pretty straightforward in concept.

But looking closer (as we will in a moment), I was seeing a rather beefy stack – one that would never fit in the kinds of small devices that we might find out at the edge of the IoT. Upon inquiring about that, the explanation made sense, if being somewhat unsatisfying. It all goes to what you mean by “edge” and “IoT.”

The Edge of What?

Back in the earlier days when communications were taking off – when we popularized those drawings that had the mysterious “cloud” in the middle – there was a lot of focus on the core network. Those are the heavyweight pipes at the Center of Everything that push all the traffic around until it gets to… well, all the local networks around the core network. It would appear that these were two different contexts, and data would be handed off from the core network to the local network as it arrived. Or vice versa.

And where was that data handed off? At the edge. “The edge of what?” you ask. The edge of the core network. So the “edge” wasn’t the edge edge – the real edge where the whole network thing ended. It was the edge of one network, but the start of another. If you lived in the core, then whatever was outside that network was not your problem. You took stuff to the “edge” – to the edge of your world – and then it became someone else’s problem (and the vocabulary changed there too).

And so it is with the IoT. Yeah, there’s still that core network. So where is the “edge” in this context? No, not the actual edge (that would be too obvious); it’s where the internet meets the local network: at the gateway or hub.

To be clear, when it comes to the IoT, not everyone uses that meaning of edge; some do mean the real edge, beyond which there is no more. Which makes it even more confusing.

Oh, That Edge!

So this edge functionality, this interop, according to EdgeX, is not about actual IoT devices living out at the real edge of things. It’s about those local boxes to which all of the things that are truly at the edge will be connected. And they’re important for interop, since Things will plug into them, and the more Things are allowed to plug in, the more flexibility we have in configuring our IoT environment.

OK, so, now that we’ve expended numerous words expounding on the meaning of the word “edge,” let’s take a more specific look at what EdgeX is all about. The news had them releasing their first code batch, named “Barcelona.” It implements an architecture as shown below.

(Click to enlarge; image courtesy EdgeX Foundry)

The idea here is to implement a plug-and-play environment to which others can design so that unrelated devices made by companies that haven’t specifically set out to work together can, in fact, interoperate based on the underlying framework.

There are elements in this platform that are replaceable; they’re showed in lighter gray. The dark purple bits are the, well, core services (but not that core) that are central to the system. APIs standardize communication with those services, making it possible to add value by substituting out device, supporting, export, security, or management services.

And in each of the non-core segments, there are pre-defined elements – like specific communications protocols for talking to devices – as well as room for “additional services.” That keeps things flexible and allows for future growth at all levels.

Services are implemented as “microservices”; this allows them to operate in isolation so that, if one service goes south, it doesn’t mess up the other services. Or if someone hacks one service, they can’t necessarily break into another one. In an environment where each service may have a different author, this is critical.

There are four main core services:

• The registry and configuration component keeps track of all of the installed microservices.
• The metadata component is similar, but it keeps track of all of the sensors and other connected devices, including the type of data generated and where that data goes. It also tracks what commands apply to the connected devices. It doesn’t collect the data, however, nor does it send any commands to the devices. Those are handled by the next two components.
• The core data component acts as a manager of and local repository for the data collected by sensors or any other generator of data. It can be referenced locally, or it can simply act as a data waystation pending transfer up to the cloud or to some other more permanent repository. To be clear, “permanent” is a relative term; the core data, even if temporary, is persistent.
• Finally, the command component handles the direct issuing of commands to the devices. Given the RESTful nature of the interface, commands come as variations of GET and PUT.

Microservices can be created by developers using the EdgeX SDK; it, as well as created code, can be downloaded from the EdgeX Factory site.

Ideally, you end up with a flexible infrastructure that can be built upon with minimal risk of breaking what’s already working. Services can be loaded onto a particular hub or gateway according to the functions needed for its particular installation.

The remaining user problem that must be addressed is how someone, upon buying such a gateway, goes about provisioning it with the specific services required. Given the industrial focus, there are likely to be resources available for such configuration in a way that would probably not work for consumers, where the details of adding services would need to be completely transparent. (Or, wait, is it opaque? Gah! Words!) But that’s a problem for a system maker, not the framework.

This also allows for foggish implementations, keeping some data and calculation local – especially for time-sensitive operations.

Of course, fog operates next to the ground. Which breaks the “edge” metaphor. Which could mean we could return the meaning of “edge” to actual edge…

More info:
EdgeX Foundry

• 
• 
• 
• 
•