Edge vs Cloud
Where physical-system workloads should run-and why the strongest architecture is often hybrid.
Edge and cloud are not competing destinations for the same workload. They are different execution locations with different latency, connectivity, data-governance, and operating characteristics. The right architecture keeps time-sensitive work near equipment, uses cloud services where aggregation and reach matter, and makes the boundary between them explicit.
Edge versus cloud is a workload-placement decision
Edge computing executes software near the cameras, sensors, machines, or other physical assets that produce the data. An edge node can acquire inputs, run local processing, retain evidence, evaluate events, and perform an immediate operational response without making each step dependent on a wide-area connection.
Cloud computing executes software in centrally operated infrastructure reached over a network. It is well suited to workloads that benefit from elastic compute, shared data, organisation-wide access, long-term aggregation, central services, and collaboration across locations.
The poor question is “edge or cloud?” The useful question is “which part of this workflow cannot tolerate distance, disconnection, or unrestricted data transfer, and which part improves when it is shared centrally?” For most physical systems, that produces a hybrid answer.
Compare the properties that affect operations
| Decision factor | Edge execution | Cloud execution |
|---|---|---|
| Latency | Short local path from device to compute and action; appropriate when a response is time-sensitive. | Includes network transit and remote service processing; appropriate when a short delay does not change the outcome. |
| Connectivity tolerance | Can continue local acquisition, processing, storage, and rules during an upstream outage if designed to do so. | Depends on a working route to the remote service for the workload being performed. |
| Raw-data movement | Raw streams and measurements can remain at the site; selected results are exported. | Central storage and processing are convenient, but high-volume or sensitive raw data must be transferred and governed. |
| Local device access | Directly connects to plant protocols, cameras, serial buses, and local networks. | Usually requires a gateway, agent, or upstream connector to reach field equipment. |
| Fleet-wide view | Each node owns its local context; a separate management path is needed for estate visibility. | Central services naturally support shared views, aggregation, and cross-site collaboration. |
| Compute elasticity | Constrained by the hardware at the site and the maintenance model for that hardware. | Can add centrally managed compute capacity for suitable workloads. |
| Failure domain | Limits a site failure to the affected node or location when nodes are independently designed. | Can simplify service management, but an upstream outage or service issue can affect every dependent site. |
| Lifecycle operations | Requires disciplined node configuration, monitoring, upgrade, and recovery practices. | Central deployment can simplify common-service changes, while device-side dependencies still need management. |
Neither column is universally superior. A monthly quality report has different placement requirements from a live safety-adjacent visual check, and a central model-training workload has different requirements from a local inference or device-control path.
Keep the workload at the edge when the physical process sets the terms
- The response is time-sensitive. A detection, alarm, control decision, or data capture must happen close to the input rather than after a network round trip.
- Connectivity is variable. Devices must continue recording, polling, processing, or applying local rules during an upstream outage.
- Raw data is high-volume. Continuous video, acoustic measurements, or dense sensor streams are expensive or unnecessary to move in full.
- Data locality matters. The organisation needs to retain recordings or measurements on operator-controlled hardware and export only defined results.
- Equipment uses local protocols. The system needs direct access to cameras, Modbus devices, serial equipment, MQTT clients, DAQ hardware, or a specialist local process.
Banalytics is designed for this local operating layer. Its Agent runs close to physical systems and provides device connectivity, tasks, storage, event handling, dashboards, and integrations. A processing module can remain independent while Banalytics manages the surrounding acquisition and orchestration path. The reference pattern is documented in How Banalytics Works for Industrial Sensing.
Use cloud services where central scale and shared context create value
- Long-term aggregation. Combine selected results from many sites for reporting, planning, benchmarking, or enterprise analytics.
- Collaboration across teams. Give geographically distributed stakeholders access to the same approved reports, datasets, and workflows.
- Elastic or specialised compute. Run suitable batch processing, large-scale training, or workloads whose demand is too variable for fixed site hardware.
- Central business systems. Connect approved operational outcomes to enterprise applications, customer systems, maintenance processes, or data warehouses.
- Common services. Operate shared identity, reporting, release, or integration services where a central dependency is acceptable and deliberately managed.
These are not reasons to move every device interaction to the cloud. They are reasons to export a well-defined outcome from the edge: an event, measurement, status change, report, selected file, or aggregate dataset with enough context for the downstream purpose.
Make the local critical path independent; share the resulting context
A hybrid architecture separates the local data plane from the central management and integration planes. At the site, the edge node connects to equipment, performs the local workload, stores what needs to remain local, and applies rules that must continue during isolation. Upstream systems receive selected outputs and provide the broader visibility or compute services that are useful when a connection exists.
With Banalytics, Portal Integration keeps the local Agent discoverable through a WebSocket signalling channel, and an authenticated browser session can establish a peer-to-peer WebRTC connection for remote data, media, file transfer, and shared access. This gives operators remote reach without placing the portal in the local acquisition or processing path. See Portal Integration for the connection model.
Choose what crosses the boundary deliberately
The edge-to-cloud boundary should be a contract, not a by-product of an implementation. Define the producer, consumer, data shape, expected rate, retention, access control, failure behaviour, and audit evidence for each flow. That discipline prevents two common problems: sending too much raw data without a purpose, and sending too little context for a downstream consumer to make a valid decision.
| Keep or compute locally | Commonly publish upstream | Reason for the split |
|---|---|---|
| Live camera and sensor acquisition | Selected events, thumbnails, clips, or measurements | Preserves latency and bandwidth while sharing the operational outcome. |
| Immediate rules and bounded local actions | Action records, alarms, and work requests | Local operations continue during disconnection; central teams gain visibility. |
| Raw high-rate streams and local buffers | Derived features, summaries, and approved training samples | Controls data transfer while making analysis possible at a wider scale. |
| Machine and site configuration | Approved status, version, and health information | Retains local ownership while supporting fleet operations and compliance evidence. |
Banalytics can publish structured results through components and integrations such as MQTT, APIs, databases, files, and ZeroMQ. The transport should match the consumer contract rather than becoming a universal replacement for the local runtime.
Decide placement one workflow at a time
- Name the operational outcome. State exactly what the workflow must accomplish and who depends on it.
- Set the outage requirement. Decide whether it must continue for seconds, hours, or indefinitely without an upstream service.
- Measure the data path. Estimate data rate, latency tolerance, local storage, and the cost or risk of moving raw inputs.
- Identify the authority boundary. Separate advisory analytics, local operational automation, and safety functions with their appropriate owners.
- Define the exported result. Publish the smallest useful data package with enough context, provenance, and failure handling.
- Test the disconnected case. Prove that the local workload behaves as designed when the upstream path is intentionally unavailable.
For systems that interact with the physical world, edge versus cloud is rarely a one-time platform choice. It is an architectural practice: place each workload where it can meet its operational contract, then integrate the resulting system through explicit, manageable boundaries.