Edge Computing
Edge Computing
What is edge computing?
- Processing data right where it’s generated
- Fast, works offline, better for security
- How edge and cloud split the work
The first thing that changes when you adopt edge computing is where decisions are made. Before, field equipment was a terminal that uploaded data and waited for an answer to come back. Once you add edge, a device next to the equipment checks thresholds and issues stop signals on its own. That decides whether a line keeps running or stops during a 30-minute network outage. The cost structure shifts too: instead of uploading thousands of raw sensor readings per second, only summarized results go up, and network and storage costs fall together.
The edge is not one block but a set of layers. Device edge puts a chip in the device itself, gateway/server edge sits at the line or store level, and MEC (multi-access edge computing) runs at carrier base stations. Each covers a different segment. In practice, the deciding factor is acceptable latency: if the task can tolerate a 100–200 ms round trip, the cloud is enough, and if it demands under 10 ms, compute has to move right next to the equipment. Edge computing is often confused with a CDN, but a CDN stores pre-built content closer to users, whereas edge computing performs computation and decisions directly on site.
The most common misconception is that deploying edge makes cloud costs disappear. In practice, what you manage grows from a handful of servers to hundreds of field devices, and the operational burden grows with it. Suppose you install 200 edge boxes across 12 factories without building a remote deployment system. Every time you change the inspection model, engineers have to drive from site to site plugging in USB drives, and every site ends up running a different model version. 'The data never leaves the site, so it’s safe' is only half true, too: a device in an unlocked cabinet on the floor can be physically pulled out, and an edge device with security patches two years behind can become a way into the internal network. Edge isn’t a replacement for the cloud; it’s one more operations team to run, and that is closer to reality.
Ilyoung JungExpert in smart factories, equipment management, and the Fourth Industrial Revolution
Jaryong KooMarketing Ph.D. and leading authority on AI, data analytics, and personal branding| Category | Edge Computing | Cloud computing |
|---|---|---|
| Processing location | Where the data is generated | Central data center |
| Strengths | Fast · Offline · Secure | Large-scale, comprehensive analysis |
| Use case | Instant response (autonomous driving, factories) | Heavy analysis and storage |
A distributed computing approach that has grown alongside demand for IoT, 5G, and real-time processing, offsetting the latency and bandwidth limits of the cloud.
Consider a hypothetical case. Company A, an auto-parts injection molder with 480 employees and KRW 230 billion (≈ US$172,078,400) in annual revenue, relied on a cloud AI for visual inspection of its products. Uploading an image and getting a verdict took a 700 ms round trip, which couldn't keep up with a line producing 40 units per minute, and defects slipping through brought in three customer claims a month. The company launched a four-month move to the edge.
- Deputy Manager Choi of the production engineering team pulled two weeks of logs and found that 480 ms of the 700 ms was spent transferring images. One line, 'the compute isn't slow; the round trip is the problem,' set the direction of the project.
- The IT team placed one GPU edge box on each of three lines and sent down only the inspection model. By splitting the work, with training in the cloud and inference on site, inspection time dropped from 700 ms to 18 ms.
- When the facility team lead asked, 'Won't the line stop again if the connection drops?', we also built in an offline mode: during a network outage, the edge inspects on its own for up to 4 hours, then pushes the results up once the connection is back.
- Operations were the next hurdle. The quality and IT teams moved to remote, batch model deployment, so a retrained model is applied to all three lines at once and versions are tracked from a single management screen.
- After four months of transition and two months of stabilization, defects slipping through fell from 3 per month to 0.3, line utilization rose from 82% to 91%, and image transfer volume dropped 94%, cutting cloud costs from KRW 11 million (≈ US$8,230) a month to KRW 2.4 million (≈ US$1,800).
- Sites that need an instant response (autonomous driving, factories)
- Handles unstable networks and offline use
- When data can't leave the premises
- Heavy, comprehensive analysis (→ cloud)
- When device resources are very limited
- Tasks where real-time response isn't critical