What it is
Edge computing means running part of your application close to the people, devices or machines that use it. The edge is not one product or one place. It is a pattern: a small server in a store cabinet, a gateway on a factory floor, or software inside a vehicle. The aim is to make decisions near the data instead of sending every reading to a distant cloud region.
That placement changes what you can promise. A camera can inspect a part and reject it without waiting for a round trip to a data center. A store can keep taking payments when the WAN link drops. Edge computing also lets you keep sensitive data local when a rule or contract requires it. It does not replace the cloud. Most designs split work: fast local control at the edge, reporting and long-term storage in the cloud.
Think of it as a tier, not a destination. Devices produce data. A nearby edge node filters, buffers and acts on it. The cloud provides identity, updates, dashboards and archives. If you cannot say which decisions happen locally and which happen centrally, you do not have an edge design yet.
How it works
A typical edge system has four parts. Devices and sensors collect readings or images. A gateway translates local protocols such as Modbus, OPC UA or MQTT and gives each device an identity. An edge node runs containers that filter data, run a model or control a machine. The cloud runs deployment, certificates, logs and long-term storage.
Data flow matters more than hardware. Decide what must be answered now and what can wait. A vibration reading may trigger a stop in milliseconds; the same reading can upload once a minute. Use store-and-forward queues with clear limits, because disks fill during an outage. Set local cache TTLs and MQTT quality of service levels that match the risk. If you use Kubernetes at the edge, treat the node as a replaceable appliance, not a pet server.
Operations are the hard part. Edge nodes sit in places with no cooling team, no badge access and unreliable power. You need signed remote updates, a rollback path, capped local logs and a way to recover a node without sending someone with a laptop. Authenticate devices with certificates, encrypt traffic with TLS, segment the edge network from the corporate LAN and rotate credentials. A stolen gateway should not become a door into your cloud.
Why it matters for a business
Edge computing matters when a round trip is too costly. That cost can be latency, lost bandwidth, a dropped link or a compliance rule. A production line that needs a reject signal before the next part arrives cannot depend on a link to another region. A retail chain with thin connections needs local checkout and inventory lookup to survive an outage. These are business constraints, not technology preferences.
It also changes support. You are no longer running one central system with a known environment. You run many small sites with different power, network and physical access. That can be worth it when downtime stops revenue or creates safety risk. It is rarely worth it just to save cloud spend. Count the cost of power protection, spares, remote hands and patching before you commit.
Use edge computing for decisions that must be local. Keep reporting, analytics, model training and long-term records centralized unless a rule forces them out. That split keeps the edge simple and gives you one place to see the whole estate. If every site runs its own database and upgrade process, you have built a small data center per store.
Common mistakes
The first mistake is treating the edge as a tiny cloud. A central region has redundant power and cooling. A store cabinet has a cleaner with a mop and a circuit shared with a fridge. Design for heat, dust, vibration, brownouts and accidental unplugging. Use a UPS, lock the cabinet, label cables and monitor temperature and disk health.
The second is skipping the offline path. Test what happens when the WAN link is cut for an hour. Can the site still do its core job? Does the queue fill the disk? Does the screen show stale data as if it were live? Write those answers into acceptance tests. Also test a failed update, an expired certificate and a node replacement. If recovery needs a specialist on site, the design is too fragile.
The third is poor visibility. Central dashboards often stop at the gateway, so no one notices a full disk or clock drift until a site fails. Ship logs and metrics with local buffering. Alert on queue depth, certificate expiry, disk wear and missed heartbeats. Keep an inventory of site, hardware, software version and owner. Without that list, every incident starts with a search.
A fourth mistake is putting too much logic at the edge. Every local feature must be deployed, patched and tested at every site. Keep edge code small. If a rule can wait a few seconds, it does not need to live in the store.
How to get started
Start with one decision that must be local and one site where you can measure it. Write the decision in plain terms: reject the part, open the gate, keep checkout running. Set a test: maximum response time, behavior during a link cut, data loss allowed, and who gets alerted. If the test cannot fail, it is not a test.
Build a reference design before you buy hardware. Include device identity, the local runtime, the cloud control plane, the update and rollback path, logging and data retention. Pick hardware with a support term and a replacement plan. Check the site for power, mounting, signal and physical access. Run a small pilot with a network cut, a power cut and a software rollback, then decide whether to scale.
You have options. Your team can build it, a systems integrator can own site work, or a structured discovery can settle the architecture before you commit. Cloudverg's Discovery and roadmap sprint is $9,500/month for a fixed two-week scope, and it ends with diagrams, a phased roadmap and a fixed price for phase one. Keep the first deployment small and document the support model before site two.
Frequently asked questions
Is edge computing the same as cloud computing?
No. Edge computing runs part of a workload near devices or users, while cloud computing runs centralized services in a provider region or your data center. Most designs use both.
Do I need edge computing for every IoT project?
No. Many IoT projects work by sending data to the cloud and accepting a short delay. Consider edge computing when a local decision must be fast, the link is unreliable, or data must stay on site. Test the offline case first.
What is a simple example of edge computing?
A store server that keeps checkout working when the internet link drops is one example. A factory gateway that stops a machine when a sensor crosses a limit is another. The local node handles urgent work; the cloud handles records.