There’s a Gartner prediction floating around that 75% of enterprise data will be created and processed outside traditional data centers by 2025. Up from roughly 10% a few years ago.

I don’t know if 75% is exactly right. Gartner predictions have a habit of being directionally correct but numerically ambitious — like that friend who’s always “about to start a startup.” What I do believe is that the center of gravity for compute is shifting, and the architecture of that shift matters more than whatever marketing label gets slapped on it.

What “Edge” Actually Means #

The word “edge” gets used to describe everything from a Cloudflare Worker running at a CDN pop to an industrial sensor in some manufacturing plant. That range makes the term almost useless in technical conversations — you have to ask “which edge?” every time someone brings it up.

Here’s a more useful model: four tiers, layered from centralized to distributed.

Cloud data centers. The traditional centralized facilities. Massive scale, high redundancy, far from end users. This is where consolidation workloads live: batch analytics, training ML models, archival storage. The stuff that doesn’t care about milliseconds.

Edge data centers. Smaller facilities positioned closer to population centers or specific industries. Think of a 5-10 rack deployment at a cell tower site, or a micro data center humming away in a hospital basement. They handle latency-sensitive processing that can’t wait for a round trip to us-east-1.

Edge devices. Gateways, routers, on-premise servers. They aggregate and pre-process data from the next tier down before deciding what actually needs to go upstream.

Edge things. Sensors, cameras, IoT endpoints. They produce data but have minimal compute. The interesting question — the one that determines your architecture — is always: how much processing happens here versus somewhere else?

The real architecture isn’t “edge instead of cloud.” It’s hybrid, with data and compute flowing between these tiers based on latency requirements, bandwidth constraints, and data sovereignty rules. The edge handles what needs to happen fast; the center handles what needs to happen at scale. Simple in theory, messy in practice.

Why Now #

Edge computing as a concept isn’t new. Content delivery networks have been caching assets at edge locations for decades. What’s changed is the set of workloads that actually benefit from edge processing.

Real-time inference is the big one. Running an object detection model on a video stream at a factory floor requires processing frames in milliseconds. Send every frame to a cloud region, run inference, wait for results to come back — congratulations, you’ve built a system too slow for anything time-critical. Doing inference locally (on an edge device or at an edge data center) keeps the loop tight.

5G helps too, though its impact is uneven. In dense urban areas where 5G rollout is actually progressing, the combination of high bandwidth and low latency creates a viable transport layer between edge devices and edge data centers. In rural areas? 5G is still mostly a promise. That gap matters for planning — you can’t assume uniform connectivity.

Then there’s data gravity. Once you’re generating terabytes per day at a single location — a factory, a hospital, a retail chain — moving all that data to a centralized cloud gets expensive fast. Sometimes legally complicated, too. Processing locally and sending only summaries or exceptions upstream is often the more practical architecture. Not sexy, just practical.

Omdia Research projects edge server deployments will double to 4.7 million by 2024. That number tells you something about where infrastructure investment is heading, even if the exact figure is probably wrong.

The Hybrid Pattern #

What I find interesting is that edge computing hasn’t produced some revolutionary new architectural paradigm. It’s mostly made existing patterns more distributed.

You still have services, APIs, databases, message queues. The difference is that some of those components now run at the edge tier instead of — or in addition to — the cloud tier. The orchestration challenge is where the real engineering work lives: keeping state consistent across tiers, routing requests to the right layer, handling failures when connectivity between tiers drops. That last one especially — what happens when your edge node can’t phone home for six hours?

Kubernetes is playing a role here. K3s (a lightweight Kubernetes distribution) can run on ARM devices with 512MB of RAM. KubeEdge extends Kubernetes to edge nodes. The abstraction layer stays the same; only the deployment targets change. Whether that’s the right abstraction for edge workloads is debatable — I’ve seen plenty of debates about whether Kubernetes is too heavy for constrained devices — but it has the advantage of being familiar. Teams already know it.

The cloud providers are all building their versions of this. AWS Outposts puts AWS infrastructure on-premise. Azure Stack Edge does something similar. Google has early work in the space. The pitch is consistent: same APIs, same tooling, different location. How well that promise holds up when the edge node loses connectivity to the control plane for six hours? That’s a different question. One that marketing slides don’t answer.

What This Means for Application Developers #

If you’re building cloud-native applications today, the edge probably isn’t changing your architecture tomorrow. But it’s worth understanding the trajectory.

The applications where edge matters right now are specific: real-time video analytics, industrial IoT, autonomous vehicles, AR/VR with tight latency budgets, healthcare devices that can’t tolerate network hops. If that’s not your domain, the cloud data center remains the right default. Don’t overcomplicate things.

Where it gets interesting for everyone is the CDN evolution. Services like Cloudflare Workers and Fastly Compute@Edge are turning CDN pops into general-purpose compute platforms. Running application logic — not just caching — at 200+ locations worldwide. For web applications with global audiences, that’s a meaningful architecture option that didn’t really exist three years ago.

The shape of the edge isn’t a single thing. It’s a gradient from massive centralized facilities down to tiny embedded devices, with computation distributed across the spectrum based on what each workload actually needs. The engineering challenge is building systems that work across that gradient without drowning in operational complexity.

We’re early in figuring that out. But the direction is clear enough to start paying attention.