The question “cloud or edge?” is often presented as a choice between two competing technologies. For most teams it is a design decision: which work needs to happen near the user or device, which can wait and which needs shared data and central management?
There is no single right architecture for every product. There is, however, a practical way to narrow the options without starting with the most popular tool.
Start with the consequence of delay
Record what happens if a task is delayed by a few seconds or the network drops. If functionality needs to continue locally, for example a device must record or alert without a continuous connection, local processing has a specific role. If the task involves analysis over time or combining data from many locations, central infrastructure may be more appropriate.
Describe the requirement as a limit rather than a wish: “the application must work offline for this key task” is a requirement that can be designed for. “We want it to be fast” does not yet say where the code should run.
Calculate where data are produced and used
Map a piece of data's journey: which device it starts from, where processing is needed, which part must be retained and who uses it later. Sending every event to a central system unnecessarily may create additional cost, traffic and complexity. Conversely, if every location maintains its own truth, teams may end up with inconsistencies, difficult updates and an uncertain picture.
Measure the operational burden
Local execution does not remove the need for operations; it distributes it across more locations. Who installs updates, monitors failures, manages access and confirms that a device is running the correct version? If the team cannot support that burden, a more centralised solution may be safer and cheaper overall, even if it is not fastest at every location.
Consider data management in advance
Define which data are sensitive, which need to leave the device and which can be transferred as a summary or result. Limit collection to what serves the function. Then design updates, copies, deletion and access controls for both local and central systems. “On-device processing” alone does not guarantee better protection if data remain unprotected there.
Calculate the full lifecycle cost
Compare not just compute pricing, but networking, storage, installation, support, updates and troubleshooting time. Use a month of actual traffic or a representative test workload. State your assumptions explicitly and measure again if volume or usage patterns change.
Try a hybrid solution only when there is a reason
Many products can keep a narrow function on the device, preprocess locally and synchronise what is needed to a central service. This can support offline behaviour and a collective view, but adds synchronisation rules and failure points. First sketch the workflow on paper and test what happens when the network drops, a request repeats or a version changes.
A short decision rule
Prefer execution near the source when immediate response or temporary network independence is essential and you can support the devices. Prefer central execution when shared management, consolidation or simpler operations are more valuable. When both are needed, describe clearly which work happens where and why. That statement is the most useful check of an architectural decision.
This cloud and edge selection framework is an original analysis developed by DigitalNow and does not assess a specific supplier.