This article is based on reporting originally published by Wired (August 2017). Company details, funding figures, and product names reflect conditions at the time of the original report.
The Latency Problem That Cloud Can’t Solve
For the better part of a decade, the dominant model for delivering computing power was elegantly simple: funnel everything through massive, centralized data centers. Amazon, Microsoft, and Google built enormous server farms—sometimes occupying the equivalent of city blocks—and the rest of the industry followed. For web search, social networking, and video streaming, that model works exceptionally well.
But a new class of applications is exposing a hard physical limit of centralized cloud: the speed of light. When data must travel hundreds of miles from a device to a regional data center and back, the round-trip takes roughly 100 milliseconds. For streaming a web page, that is imperceptible. For a self-driving car deciding whether to brake, or for an augmented-reality headset trying to keep a virtual object anchored to a moving surface, 100 ms is an eternity.
Why Milliseconds Matter
The human vestibulo-ocular reflex—the neurological mechanism that coordinates eye and head movement—operates in roughly seven milliseconds. When an AR or VR experience requires a server response and that response arrives 70 ms later, the mismatch between what the eyes see and what the inner ear expects triggers disorientation and nausea. Eliminating that gap is not a nice-to-have; it is a prerequisite for immersive experiences to function at all.
The latency ceiling affects a growing list of workloads:
- Autonomous vehicles — real-time processing of road conditions, vehicle-to-vehicle communication, and collision avoidance requires decisions measured in milliseconds.
- Mobile AR/VR — rendering convincing immersive experiences on a smartphone depends on sub-20 ms server round-trips.
- Cloud gaming — streaming interactive games at 60 frames per second demands latency low enough that controller input feels immediate.
- Industrial robotics and drones — remote operation and autonomous decision-making in physical environments cannot tolerate unpredictable network delays.
The Edge Computing Model
The architectural response to the latency problem is edge computing: distributing processing power geographically so that computation happens close to the devices that need it. Rather than routing all traffic to a handful of mega-datacenters, an edge network seeds the landscape with smaller compute outposts—micro datacenters, cell-tower co-locations, local servers—that can respond in 10 to 15 milliseconds instead of 100.
This is not a replacement for the centralized cloud. Workloads that are not latency-sensitive—batch analytics, machine-learning training, long-term storage—will continue to run cost-effectively in large regional data centers. Edge computing is a complementary layer that handles the subset of work where physical proximity to the end device is critical.
Who Is Building the Edge?
Hyperscalers Moving to the Edge
The major cloud providers recognized the latency problem and began extending their platforms outward. Microsoft announced testing of Azure IoT Edge, designed to push cloud functions directly onto customer-operated devices. Amazon Web Services opened general availability of AWS Greengrass, which extends Lambda functions and messaging to devices running on local networks. Both services require customers to manage local hardware, which represents a different operational model than fully managed cloud—a tradeoff some teams find acceptable and others do not.
Content delivery networks (CDNs) such as Akamai, Cloudflare, and Amazon CloudFront already operate geographically distributed “edge locations” that cache and serve static and streaming content closer to end users. In many respects, CDNs were the first generation of edge infrastructure; the current wave extends the concept to general-purpose compute rather than content caching alone.
Telecom Operators and 5G
Mobile network operators see their 5G infrastructure rollouts as a natural opportunity to add edge compute capacity. Cell towers and central offices are already distributed across metropolitan areas; adding server hardware to those locations means data only needs to travel a few miles rather than hundreds. AT&T, for example, announced plans (at the time of the original Wired report) to build a mobile edge computing network targeting single-digit millisecond latency, leveraging network virtualization software to dynamically balance workloads across the mobile infrastructure.
Startups Filling the Gap
Several startups moved early to build dedicated edge infrastructure:
- Packet (New York City) — founded by Zachary Smith, Packet operates micro datacenters in major cities, offering customers average round-trip latencies of 10–15 ms. The company received investment from SoftBank and, at the time of the original report, was expanding to cities including Chicago, Dallas, Los Angeles, Seattle, Frankfurt, Toronto, Hong Kong, Singapore, and Sydney.
- Vapor IO (Austin, Texas) — builds micro datacenters co-located alongside existing cell towers. Its “Project Volutus” initiative partnered with Crown Castle, then the largest US provider of shared wireless infrastructure, to leverage an existing network of approximately 40,000 cell towers and 60,000 miles of metropolitan fiber. Vapor IO developed automated software to remotely monitor and manage the micro datacenters for high availability.
A Real-World Use Case: Cloud Game Streaming
Hatch, a spinoff from Angry Birds developer Rovio, built a subscription game-streaming service that lets smartphone users begin playing instantly—without downloading an app—and supports multiplayer and live-streaming features. Making mobile game streaming work at 60 frames per second without perceptible lag required solving the same latency problem that faces autonomous vehicles and AR applications. Hatch partnered with Packet to use its edge infrastructure, making it one of the first consumer-facing products explicitly built on edge compute rather than centralized cloud.
The Hatch example illustrates a broader pattern: edge computing’s value is often invisible to end users. Players will not know or care which data center processed their input. They will simply notice that the experience feels immediate—or that it does not.
The Historical Arc: Decentralized → Centralized → Decentralized Again
Peter Levine, general partner at Andreessen Horowitz, described this shift as a “back to the future” moment. The pre-2000 internet relied on a decentralized topology of PCs and client-server systems. Starting around 2005, centralized cloud computing became the dominant model, enabling massive economies of scale. The rise of latency-sensitive, device-rich applications is now pulling architecture back toward distribution—not because centralization failed, but because the problem space has changed.
Cole Crawford, founder and CEO of Vapor IO, described edge infrastructure not as a replacement for centralized cloud but as “a natural extension of today’s centralized cloud”—thousands of small regional and micro-regional data centers integrated into last-mile networks.
What This Means for DevOps Teams
As edge computing matures, engineering teams building latency-sensitive applications need to think about infrastructure architecture earlier in the design process. Key considerations include:
- Latency budgeting — identify which operations in your application have hard latency requirements and trace whether those requirements can be met by a centralized cloud or require edge placement.
- Data gravity and sovereignty — edge nodes may hold a subset of data locally; determine what must stay close to the device versus what can be processed centrally.
- Operational complexity — managing compute across dozens of geographically distributed nodes is harder than managing a single-region cloud deployment. Invest in automation, observability, and consistent deployment tooling (containers, Kubernetes, infrastructure-as-code) from the start.
- Hybrid topology testing — test application behavior under varying network conditions. Tools that simulate higher latency between components can reveal hidden dependencies that will break in a distributed edge topology.
- Vendor landscape — the edge infrastructure market is evolving rapidly. Evaluate managed edge services from cloud providers alongside specialized edge platform providers and telecom-operated mobile edge compute offerings before committing to a single approach.
The Takeaway
The centralized public cloud is not going away. Its economics for storage-heavy, compute-intensive, and latency-tolerant workloads remain compelling. But the expanding universe of applications that interact with the physical world—vehicles, robots, wearables, industrial sensors—operates under physical constraints that no amount of bandwidth can override. Edge computing is the infrastructure response to those constraints: putting the right compute in the right place so that the network round-trip stops being the bottleneck.
For DevOps engineers, the practical implication is straightforward: design for distributed deployment from the beginning, instrument everything, and automate aggressively. The edge is not a single product you buy—it is an architectural principle you build toward.