Edge computing: what to get right first

This is cheap to get right at the start and expensive to retrofit. If you only fix one thing about edge computing this quarter, make it the first item below.

The bill is a design document: it tells you exactly what your architecture actually does. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

Start here

Running closer to users removes latency you cannot optimise away. It is worth being explicit about, because assumptions differ quietly. The version that survives contact with a real deadline is the simple one.

Then this

Great for caching and routing, awkward for state. The teams that handle this well are rarely the ones with the biggest budgets. Check it against what you would want a competitor's site to get wrong.

Eventually

Debugging across many locations needs deliberate tooling. Getting it slightly wrong is survivable. Ignoring it entirely is not. The version that survives contact with a real deadline is the simple one.

The short version

Cloud work rewards teams who automate early and punishes teams who click through consoles. Three things worth confirming about edge computing before you move on:

• Someone can say what the current setup is without going to look
• Running closer to users removes latency you cannot optimise away — and you know whether that is true here
• There is a way to tell whether the last change to this helped

None of this needs a rewrite. Most of it is a morning's work once someone decides to do it.