Edge computing gets discussed as though it were the next stage of cloud computing, succeeding the centralised model the way cloud succeeded on-premises servers. That framing is misleading. Edge is not a successor; it is a different point on a trade-off curve, and moving along that curve costs you things you may not want to give up.
This piece looks at what you gain, what you lose, and how to tell which side of the line a given workload falls on.
The two models
Traditional cloud computing concentrates compute in a relatively small number of very large data centres. Your application runs in a region — perhaps a few regions — and requests travel there and back. The advantage is concentration: one place to deploy, one database to reason about, one set of logs.
Edge computing pushes execution outward to many small locations close to users. In practice this means one of two things. Either you are running code at CDN points of presence, of which a large provider may have hundreds worldwide, or you are running compute on or near the devices themselves — a gateway in a factory, a server in a retail branch, a processing unit in a vehicle.
The physical driver is the speed of light, which is not negotiable. A round trip from London to a data centre in Virginia costs somewhere around 80 milliseconds before any processing happens. From London to a London point of presence, under 10. For most web requests that difference is barely perceptible. For some workloads it is the entire problem.
What edge genuinely solves
Latency-sensitive interaction. If a system must respond in single-digit milliseconds, distance decides the architecture. Industrial control, real-time video analysis, augmented reality, high-frequency trading, and multiplayer game state all sit here.
Bandwidth economics. A factory with fifty cameras generating continuous high-resolution video cannot economically ship all of it to a central region. Processing locally and sending only events — “person detected in restricted zone at 14:32” — reduces the data volume by orders of magnitude. The same logic applies to any dense sensor deployment.
Operating through disconnection. A retail point-of-sale system, a ship, a remote site, a vehicle. These need to keep working when the link drops, which means local state and local compute are requirements rather than optimisations.
Data residency. When regulation requires that data stay within a jurisdiction, processing it locally and transmitting only aggregates or anonymised results is often simpler than negotiating cross-border transfer arrangements.
Cheap global performance for read-heavy workloads. Serving personalised but largely static content from edge locations — routing, authentication checks, A/B assignment, localisation, caching — gives a meaningful speed improvement for very little architectural cost. This is the most commonly useful category by a wide margin, and also the least dramatic.
What edge costs you
The difficulties are almost all consequences of one fact: you now have many copies of your system instead of one.
State becomes genuinely hard. With a single database in one region, you get straightforward consistency. Distribute state across hundreds of locations and you are choosing between strong consistency with latency penalties that undo the reason you went to the edge, or eventual consistency with all the conflict-resolution logic that implies. This is not a tooling gap that will be solved by a better product; it is a distributed systems constraint.
Debugging degrades. A bug affecting 0.3% of requests in one region is findable. The same bug appearing only at particular locations, under particular network conditions, with slightly different runtime versions, is an unpleasant afternoon. Observability tooling for edge deployments is improving but remains behind what is available centrally.
Deployment is no longer atomic. Rolling out to hundreds of locations takes time, and during that window multiple versions of your code are live simultaneously. Every change has to be compatible with the version before it, which is a discipline many teams have not needed to develop.
Runtimes are constrained. Edge platforms typically impose limits on execution time, memory, and available APIs. Many run restricted JavaScript or WebAssembly environments rather than full containers. Code that runs fine in a normal server process may need rewriting.
Physical hardware brings physical problems. On-premises edge devices need someone to install them, replace them when they fail, secure them physically, and keep their firmware current. A cloud region has staff for this. A cupboard in a branch office does not.
A way to decide
Work through four questions in order.
Does the workload require sub-50ms response including network time? If no, centralised cloud is almost certainly sufficient and much simpler. Most business applications answer no. Be sceptical of latency requirements that have not been measured against actual user experience rather than asserted in a meeting.
Is the data volume at the origin too large or too expensive to transmit? If a site generates terabytes daily and you need conclusions rather than raw data, local processing is likely justified.
Must it function while disconnected? If continued operation during an outage is a hard requirement rather than a nice-to-have, local compute is mandatory.
Does regulation require local processing? If so, the decision is made for you.
If all four answers are no — which they will be for a great many applications — you should be running centrally, with a CDN in front for static assets and perhaps a small amount of edge logic for routing and caching. That combination gets most of the perceived performance benefit for almost none of the architectural cost.
The hybrid pattern that actually gets used
In practice, mature systems rarely choose one model. They split responsibilities along a predictable line.
Time-critical and high-volume processing happens at the edge, close to where the data originates. Results, aggregates, and events flow to the centre. Training, analytics, long-term storage, coordination, and configuration management stay central, and updated models or rules are pushed back out.
A retail chain illustrates the shape well. In-store systems handle transactions, inventory checks, and camera-based analytics locally, so the store keeps trading if the connection drops. Aggregated sales and stock data flow to a central platform overnight. Demand forecasting and pricing run centrally against the full dataset, and updated pricing rules are distributed back to stores.
Neither layer is subordinate. Each does the work it is structurally suited to.
Cost, briefly
Edge pricing is difficult to compare directly with central compute because the units differ — invocations and CPU-milliseconds rather than instance-hours.
Three patterns hold reasonably well. Edge platforms are usually cheaper for short, high-volume, bursty work, because you pay only for execution rather than for idle capacity. They are usually more expensive per unit of sustained compute, so long-running processing is cheaper centrally. And the largest saving is frequently not compute at all but egress: bandwidth charges for shipping raw data out of a facility often dwarf the processing cost, which is why the bandwidth argument for edge tends to be the most financially persuasive one.
Hardware-based edge adds capital expenditure and ongoing maintenance that cloud-hosted edge does not, and this is regularly underestimated in business cases.
The honest summary
Edge computing is a specialised tool that solves latency, bandwidth, resilience and residency problems very effectively, at the cost of significant additional complexity in state management, deployment and debugging.
If you have one of those four problems, it is worth the complexity. If you do not, adopting it will make your system harder to operate in exchange for a performance improvement your users cannot perceive.
The useful question is never “should we move to the edge?” It is “which specific parts of this system have a physics problem?” — and for most systems, the honest answer is a small handful, or none.