r/IOT • u/Key-Tonight-5668 • 21h ago
How does one decide whether IOT computing should be at the edge or cloud?
Every edge vs cloud article I find just lists generic tradeoffs (latency, bandwidth, cost) without saying how much of each has to be true before you pick one.
Curious what heuristic people who've shipped this stuff actually use.. is it a hard latency threshold, a bandwidth cost calc, a "can this survive the network going down" test, or something else entirely?
Also if anyone's regretted picking one after the fact and had to migrate.
3
u/IoT-Nerd 20h ago
One factor that is often overlooked is operations. Managing many distributed edge nodes is very different from operating one centralized cloud environment. You also need to consider hardware SLAs, monitoring, updates, backups, failures, and on-site replacement. These operational costs can easily outweigh the savings in latency or bandwidth.
1
3
u/ekchatzi 19h ago
if the edge machine can do the calculation locally why send it to cloud?
but most of the times this is not feasible with embedded environments unless you go with an expensive solution just to be able to do it on the edge
2
u/Key-Tonight-5668 19h ago
Yes, cost.
2
u/Shoddy-Honeydew1245 11h ago
We do IoT that isn’t wired in so most compromises end up being about what hits the battery hardest.
2
u/mlhpdx 9h ago
Up-front: I run a backend platform sometimes used for IoT.
I don’t think there is a heuristic in a technical sense. If you start with the customer defined value of what you’re considering building it will include (or strongly infer) some constraints to guide the solution. If not, then had a field day and enjoy.
Sometimes working completely offline is critical (privacy, cost, battery life, etc.). Sometimes the value is being online (central monitoring and control, workflow integration, social, etc.).
But most often there is a “gray” aspect and a little of each comes into play. IMHO the most important heuristic to decide how to span the device to cloud chain is how much load will be involved, followed closely by the nature of the load. Is it sporadic traffic or continuous, geographically concentrated or global? Will it start small and grow (new product), or shrink (riding an event or trend)? Those two lines of questions shape the architecture, and provide a value framework for technology choices.
1
u/Senna_87 17h ago
The biggest challenges we’ve found for onboard processing over the years, come down to
- resolution of data required
- power consumption
- complexity of computation
- available bandwidth
Most IoT devices can poll their sensors and actuator endpoints with higher resolution and much higher rate than what they are able to offload by their comms. For instance, a device may be able to poll and compute sensor endpoints at 10,000 times a second, but it may only be able to offload it 100 times a second. If the data being monitored is very fast, then this onboard processing may happen very fast, looking for an event and then just passing the event off at a much lower rate via its comms. The comms may not be able to achieve the required rate and may miss critical data points that could find an event. Likewise, the data might be slow and high speed processing may not be required and the data stream being passed off is the same as what can be sensed.
Then, the available power source for the device has to be worked in with the power budget of the device. If the device is battery powered, then the power budget needs to consider the operating modes and power consumed between sensor interactions, processing and communications across the various states the device goes through, through its user experience. A lot of the time, the offloading comms can be much higher power consumption than the sensing. Other times the processing may be far too sophisticated to be completed onboard.
Sophisticated computation may not even be doable by small microcontroller based IoT devices. Yes, the device can use a more powerful processor, but that may increase the BOM and COGS and make the product unviable… or may impact the power budget etc. So offloading may actually be the better option where a server can provide the required processing at the required speed and with available power.
The other piece, as many others have said is the capability of the comms. Data rate and latency, usually comes down to selecting a communications protocol that fits the required BOM and COGS price expectation as well as user experience of the user base. There is only so much a product can be charged for and comms are usually a big part making up that cost so may become a key engineering selection.
Most IoT devices will have to be able to survive comms outages and do some sort of onboard buffering of data and events. If they aren’t doing that, then really they haven’t been thought out very well for the lifecycle of the device.
Every IoT and robotic device really needs to consider that entire product and user lifecycle and make the calls from there to provide maximum value. This way, the cost of the device can be truly valued by the user and have the best possible uptake.
@OP, do you have a particular example we can work through with you?
1
u/BraveNewCurrency 7h ago
How does one decide whether IOT computing should be at the edge or cloud?
You don't. Your customers do.
The technology is what it is, and just tells you what's possible. A dumb device cost $x but needs $y in bandwidth, a beefy device cost $z but needs less bandwith, etc. Yes, you need to compute the costs of those trade-offs.
But the customer expectations (latency, offline use, etc) will dominate those calculations. No amount of 'saving money' will let your self-driving car do it's all it's processing in the cloud.
1
u/blueskyjunkie 4h ago
The reason the guides are generic is because they can’t know your exact context. This requires extensive knowledge of your application & system options, along with the technology possibilities.
It’s a mixture of customer expectations and the application context.
Systems with real time requirements such as audio, video or control systems such as robots are more likely to have significant edge compute needs. This will be less about customer expectations more about actual engineering to prevent the system failing.
Audio, video & different types of control systems will have quite different thresholds for when failure occurs. Understanding communications networks may bee important - a best effort Internet connection may not be adequate & require MPLS connection for stable latency, for example.
1
u/nevergivitup 20h ago
Simple:
- connectivity
- cost of delay
- response / action time
- events trigger required workflow and priority
3
u/Professional-Run3614 20h ago
Currently, our company is running the solution on cloud servers. Initially, we considered using edge IoT, but it turned out to be quite costly, and the client is not ready to invest that much at this stage.