There is no single "Edge" in IoT
There are 3 distinct design problems to consider for the Edge
It should be fairly clear now to anyone with even a remote interest in technology adoption that IoT (Internet of Things) and IIoT (Industrial Internet) are going to happen. You could credibly argue about hype cycle effects, timing and what successful approaches will look like. The realist in you can claim that smart home, wearables, smart cities and industrial computing may not reach the mainstream until the mid to late 2020s.
You may be proven right with regards to timing, but I’m certain that a pervasive, physical, contextual web incorporated into smart connected products + services represents the future for most industries. Its broad scale utility is derived from smartphone component economics, ubiquitously available connectivity and advances in power efficiency that leverage low cost cloud and edge computing, AI/ML and open source. Imagine what happens when any reasonably creative, technically competent individual with access to a credit card can innovate with all of this readily available tech. Exciting times for sure.
Distributed complexity is a given
Physical web data, compute and analytics combined with web APIs and apps create the compelling value that will drive smart connected product and service adoption. Managing those things at scale is non-trivial, and the right economically viable combination of those things differs case by case.
Sometimes you can afford the cost, complexity and latency needed to bring all the physical web data to a cloud service for the compute and analytics tasks. In other situations remote connectivity is so expensive, unavailable, unreliable or otherwise impractical that no viable option exists but to deploy compute and analytics at (or near) the data source. When those sources happen to be complex systems in and of themselves, and/or geographically distributed, it becomes significantly more challenging to build out and manage the desired solutions at scale. The IT/OT barrier is a legitimate concern, as are the security implications of interacting with physical devices and processes.
Then there’s the question of data ownership, both source/raw data and derived data. Data management permeates all aspects of an IoT system. I plan to address this in a separate post.
Today’s IoT platforms mainly focus on brute force data extraction
There are literally hundreds of IoT platforms out there in various forms, but they tend to cluster into cloud-centric or device-centric approaches. Most all of them either have little or no machine learning capability. Many assume that you will only deploy those capabilities in the cloud using pay-as-you-go SaaS like Amazon ML or Azure ML/Cortana Intelligence Suite.
Most of these services treat the device accessing the physical web data as relatively dumb. They focus on securely extracting that raw data so you can eventually do something with it on the cloud side. Given the highly repetitive nature of most time-series data in IoT applications, this isn’t a terrific use of network bandwidth. Even if it’s unmetered, you’re still clogging up the available bandwidth with alot of low information content data streams. Even if you're pretty good at compressing these raw data streams, you're still transporting a bunch of low information content traffic all over the place before you even know if it's worth transporting to begin with.
Many of these platforms are also limited to higher-end “gateway” class hardware. They consume a large part of the processing capacity of these devices, and are basically betting (hoping) that IoT devices will follow the performance path of smartphones, albeit at a slower pace. This severely limits their suitability in the short term by driving up costs - which inevitably slows adoption of smart connected products and services.
Also keep in mind that you still need to build the intelligence into the device to interact with whatever physical web object you’re monitoring. Most IoT platforms won’t help you there either.
This video from a16z partner Peter Levine provides an excellent summary of why edge computing will be a key part of the next generation of IoT platforms. An excellent initial example of platform efforts extending to the edge is Amazon Greengrass. Telecom operators are actively working multi-access edge computing standards as part of their 5G initiatives, though their applicability is years away and will be mostly limited to the next generation of machine to machine (M2M) deployments.
Three distinct edge problems in IoT/IIoT
There are actually three classes of problems you run into as you get near a physical web data source. Each of these cases are legitimate, affect different audiences and require specialized solutions to resolve. They will all eventually be solved of course, in a way that is most appropriate to the smart connected product scenario being addressed. Let’s “clear the fog” (pun intended) by presenting each category of problem and how solutions are likely to be architected to address them.
The Cloud Edge — a “reverse CDN” node
Wouldn’t it be great if there were a high-capacity, directly cloud connected node that stored all the real-time and near-real-time data an IoT application would need? That app wouldn’t have to interact directly with physical web data sources. If those objects went offline temporarily, the app would continue to function. Isn't this is what cloud-based IoT application developers really want? A fully decoupled, always accessible virtual representation of the physical web.
You could use high speed storage and concentrate computing capacity to run services like SparkML (MLlib), maximizing the potential value of the analytics you’re creating. Most all of the traffic between the physical web devices and the cloud would stay at this cloud edge point, preventing network disruption in the core Internet and reducing the impact on cloud infrastructure. The specialized application logic needed to directly and/or indirectly interact with the physical web devices could also be deployed on these nodes, isolating access away from the cloud applications themselves.
You could even deploy this Cloud Edge near your physical web data sources, as long as you can source high quality cloud bandwidth to the cloud edge node. Imagine parking one of these rack size machines in an industrial building, by a wind farm or at an airport gate. Scalable machine learning and IoT value creation with a persistent, high bandwidth cloud connection. Yummy.
The Physical, “On-Device” Edge
Capital equipment is expensive, and replacement cycles can often be counted in decades. A majority of this equipment was designed with physical security as its primary defense. Some of it is fixed location, some of it mobile. Equipment control and operation trumps everything else, including IoT application functions. Embedded computing capabilities, if present, are controls focused, likely to be encoded in a proprietary manner, and must function whether or not remote connectivity is available. Supervisory, monitoring and/or job control interfaces may or may not be available, and in most cases are vendor or industry vertical specific.
This is the reality most OT practitioners face. Any solution is likely vertical/industry specific and needs to securely interact with cloud services — or an on-premise Cloud Edge node — while first and foremost ensuring proper, safe and effective physical device operation. The equipment manufacturer and operator will most likely be relied on to provide data access permissions needed for IoT applications to interact with the equipment.
The Edge Gateway
An Edge Gateway directly interacts with physical web devices and is a key element needed for IoT value creation when cloud connectivity is unavailable — offline use. It is deployed in close proximity to physical web devices and will typically provide extensive local connectivity capabilities including mesh networking, RFID and/or CAN. Most of the “embedded-PC” class devices supported by cloud-based IoT platforms fit this category, though they may likely lack the rich local connectivity options needed to fully realize IoT capabilities.
Summary
Go-forward IoT solutions that interact with physical web devices will include multi-tier edge components in addition to their cloud-based application foundations. As those solutions scale the value of a 3-tier edge will become clear, and the technologies (and providers) for each of those tiers will specialize over time.
Exciting isn’t it?
#IoT #IIoT #EdgeComputing
Brad Nicholas - captured very well! The tyranny of latency, cost and security will drive the intelligent edge.
Some good points Brad. Should the three disciplines develop at the same rate? My point being, rapid advance in some areas could out pace co-depedent development in others, potentially rendering software/hardware irrelevant until all three are developing at the same level. Granted, some advancement could be utilized elsewhere, but for example, how much effort is currently being put into retrofitting IoT devices into existing machinery as well as designing new equipment with the IoT devices as part of the original design?
5G is long way . Now is LoRa and NB IOT
Hi William thanks for the comment. The whole #5G thing will take time to play out, but there's no question IoT use cases are a key driver for it. I wouldn't say IoT success is dependent on it though. It's not even something near term IoT deployment planners need to consider to be honest. I think of IoT/IIoT as much broader than any telco industry contribution to it. Telco has traditionally played where metered wide area networking on licensed spectrum is the only acceptable communication method to meet an application need. Unmetered, unlicensed network technologies are dominant in local and personal area networks for good reason, and narrow bandwidth unlicensed LPWAN network tech is also available. While I think it's highly likely telcos will end up dominating LPWAN, it's still a consideration only for specific types of IoT platform deployments.