--- title: "Edge or cloud is a latency budget, not an ideology" date: "2023-11-01T05:00:00.000Z" categories: "Digital twins" canonical: "https://xraph.com/writing/edge-or-cloud-is-a-latency-budget" --- # Abstract Three questions decide where a computation runs, and none of them are about architecture preference. What breaks if the link drops, what the bandwidth costs, and how fast the answer is needed. ## Three questions Where a computation runs should fall out of three answers rather than a preference for centralisation or its opposite. **What happens if the link is down?** If the answer involves anything unsafe or expensive, the computation runs locally. That is not an optimisation, it is a requirement, and it is the end-to-end argument doing its usual work [2]. **What does the bandwidth cost?** A vibration sensor at several kilohertz produces more data than a satellite link can carry. Something has to reduce it before transmission, and the reduction is itself a modelling decision about what matters. **How quickly is the answer needed?** If the response has to happen within a control loop, it runs locally, because the round trip does not fit in the budget regardless of how good the link is [1]. ## What edge is genuinely good at Reduction. A local process that takes a high-rate signal and produces features at a much lower rate turns an impossible bandwidth problem into an ordinary one, and it can do so with knowledge of the specific equipment. Buffering. When the link drops, the edge holds the data and delivers it later. This is the single most valuable thing an edge deployment does in practice, and it dictates the storage sizing. Safety-relevant response. Anything that must happen whether or not anyone is watching. ## What edge is bad at Anything that needs a global view, because it does not have one. Anything that needs to change often, because deploying to a thousand devices with intermittent connectivity is a genuinely hard operational problem. Anything that needs substantial compute, because the hardware is chosen for power and environmental tolerance rather than throughput. Model updates are the case that bites. A model that needs weekly retraining and redeployment to edge devices with intermittent links needs a delivery mechanism with staged rollout and rollback, which is most of a deployment platform. ## The split that has worked for me Edge does acquisition, validation against the channel specification, reduction, buffering, and any safety-relevant response. It knows about one site. Centre does cross-site analysis, model training, long-term storage, and anything a human interacts with. It knows about everything and it is allowed to be unavailable. The boundary is a queue that survives disconnection in both directions. Making that explicit early stops the design from acquiring hidden synchronous dependencies on a link that will not always be there [3]. ## The direction of data flow Worth stating because it constrains the architecture: in industrial settings the flow out of the control system should be one way by construction, not by policy [4]. That decision makes several tempting edge designs unavailable, and it is the reason the operations team will approve the deployment at all. # References 1. Edward A. Lee, "Cyber Physical Systems: Design Challenges", IEEE International Symposium on Object and Component-Oriented Real-Time Distributed Computing (ISORC), 2008 2. J. H. Saltzer, D. P. Reed, D. D. Clark, "End-to-End Arguments in System Design", ACM Transactions on Computer Systems, vol. 2, no. 4, pp. 277-288, 1984 3. Michael T. Nygard, "Release It! Design and Deploy Production-Ready Software", Pragmatic Bookshelf, 2nd edition, 2018 4. NAMUR, "NAMUR Open Architecture: NOA Concept", NAMUR Recommendation NE 175, 2020 --- *Unpublished draft. Not peer reviewed and not submitted to a venue.*