Edge computing: the questions we get asked most

There is no clever trick in this one, just a handful of decisions worth making deliberately. The questions about edge computing that come up most often on our calls.

The bill is a design document: it tells you exactly what your architecture actually does. Check it against what you would want a competitor's site to get wrong.

Do we need to care about this?

Running closer to users removes latency you cannot optimise away. That sounds obvious written down. It is still the thing most often skipped. Budget a little time for it every quarter and it never becomes a project of its own.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. The teams that handle this well are rarely the ones with the biggest budgets.

How do we know it is working?

Debugging across many locations needs deliberate tooling. There is a version of this that is over-engineered, and it is worth avoiding. If it only works because one person remembers to do something, it does not work yet.

In practice

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
• Debugging across many locations needs deliberate tooling — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If you want a second opinion on how yours is set up, ask.