The edge-versus-cloud debate usually produces more slogans than engineering. The right answer depends on latency, bandwidth, cost, security, and who consumes the data. This framework forces those trade-offs into the open.
Ask These Questions First
- How fast must the system react? Control loops and safety functions must stay on the floor - cloud round trips are for analytics, not actuation.
- How much data, and how expensive is the link? Streaming raw vibration or vision data to a data center can cost more than the analytics are worth; filter and summarize at the edge.
- Who needs the data? Plant-floor dashboards want sub-second freshness locally; enterprise KPIs and machine learning can tolerate minutes or hours from the cloud.
- What is the risk of connectivity loss? If production must continue and data must not be lost during outages, you need local buffering and store-and-forward - edge by necessity.
The Pattern That Usually Fits
Keep control and short-horizon decisions at the edge. Move aggregated, event-based, or model-ready data to the cloud for cross-site analytics, benchmarking, and ML training. The edge gateway is the integration point: it normalizes, filters, buffers, and publishes - it does not try to run the plant.
Common Failure Modes
- Cloud-first projects that stall because site connectivity is unreliable - design the offline path first.
- Edge projects that accumulate one-off scripts nobody maintains - treat edge applications like software, with versioning and updates.
- Both sides duplicating storage, leaving no single source of truth - define which system is authoritative per dataset.