Edge Computing vs Cloud Computing

Imagine a greenhouse that waters plants when the soil gets too dry. One task needs a prompt response beside the plants. Another task compares months of readings across several greenhouses. These jobs do not have to run on the same computer.

Edge describes proximity; cloud describes a service model

Edge computing places some processing near the people, devices or activity producing the data. That might mean a controller in the greenhouse, a small local server or equipment in a nearby network facility.

Cloud computing makes computing resources available as a service. Those resources may be in a large data centre, but a cloud platform can also extend to nearby sites. Edge and cloud are therefore not mutually exclusive categories: one system can use both.

ETSI’s edge-computing work covers deployments on premises and at the network edge, including cooperation with cloud providers. If the service models are new to you, start with the cloud-computing introduction.

Put the immediate response near the event

In our greenhouse, a local controller could read the sensor and operate a valve without sending every decision to a distant server. Shortening that path can reduce network delay. Filtering or summarising readings locally can also reduce the amount of data sent elsewhere.

That benefit comes from how the application is built. A nearby box that still needs a remote service for every decision will not keep the same function when the connection fails. Local processing capacity, software and fallback behaviour matter alongside distance.

Use shared capacity for the wider view

A cloud service could combine readings from many greenhouses, store their history and compare growing conditions over a season. This work can benefit from shared storage and computing resources without sitting beside every plant.

There is no universal speed or cost winner. Network travel, waiting time and the calculation itself all contribute to a response. A well-connected cloud service can outperform an overloaded local device; a quick local check can avoid a needless journey.

A practical way to divide the work

• Response time: which decision must happen promptly, and how long can the user or device wait?
• Connection loss: what should continue locally, and what can wait until the connection returns?
• Data movement: which raw data needs to leave the site, and would a summary be enough?
• Operating effort: who maintains nearby devices, and what resources or transfers will the remote service charge for?

The answers may lead to a local response loop with remote storage and analysis. They may also lead to a simpler single-location system. Adding more components is useful only when they serve the actual task.

More locations do not automatically mean more independence

One organisation can control computers spread across many places. The location of a machine and the power to change its rules are separate questions. To understand a system, look at both where the work happens and who can decide how it operates.

That distinction connects to the broader question of who controls the Internet’s different parts. For the connection between the user and the computing service, continue with the main types of internet access.