Which edge do you use with Avassa?

Almost every edge computing diagram is drawn by someone selling something. Telcos draw an edge that lives in central offices and at cell towers. Hyperscalers draw one that looks like a smaller region. Device vendors draw one that ends at a sensor. All three are real, and all three are a fraction of the picture.

A more useful map is a continuum, running from centralized compute out to the physical world, with ownership changing as you move along it: Cloud → Service Provider Edge → User Edge → Device Edge.

The Service Provider Edge is no longer a telco story

The provider-side edge splits into three, not two. Regional edge sits in IXPs and multi-tenant colocation: Equinix, Digital Realty and peers. Access edge is the carrier tier proper: cell towers, cable head-ends, central offices, hosting 5G RAN and local breakout.

Non-telco provider edge is the part most taxonomies still omit, and the fastest-growing of the three. Hyperscaler regional and local zones: AWS Local Zones and Outposts, Azure Edge Zones, Google Distributed Cloud Edge, plus CDN and neutral-host operators like Cloudflare, Akamai and Fastly. Provider-operated and consumed as-a-service, exactly like the access edge, but with no carrier relationship anywhere in the stack.

This tier is defined not by who owns the building. It is that someone else operates the whole thing and you rent it.

The gap: the middle of the User Edge

The User Edge is where the maps get worst. The common shorthand is “on-premises data centers, and then wearables”, which skips the tier where most of the interesting work is actually happening.

On-prem data center edge is the familiar end: enterprise and factory server rooms, CAPEX-owned, running virtualization, Kubernetes and GPU racks. Smart device edge is the far end: gateways, kiosks, vehicles, phones, headsets — enough memory to run containers, but constrained.

Between them sits the industrial and embedded compute edge

These are real computers (Industrial PCs, Intel NUC-class x86 mini-PCs, NVIDIA Jetson Orin, etc.), not sensors and not data centers. And they are where physical AI actually runs: real-time computer vision, defect detection, safety systems, robotics and autonomous-vehicle perception, local LLM and VLM inference, closed-loop control at 10–100ms with no cloud round trip.

They get skipped for structural reasons. Too small to be a data center, too large to be a device. Not carrier-attached, so telco-authored frameworks ignore them. And a single customer runs thousands of them across dozens of sites — which makes them an orchestration problem, not an SSH problem.

What this means

The Service Provider Edge is real and valuable, but no longer telco-only. Meanwhile, the User Edge and Device Edge sit entirely outside carrier infrastructure — and the fastest-growing part of that, industrial PCs and Jetson-class nodes running edge AI on the factory floor, falls into a category most published taxonomies don’t name. Any edge strategy built from a single vendor’s map is missing a tier. Usually the one that matters most.

Where Avassa fits in

The Avassa Edge Platform operates in exactly the tier the taxonomies skip. The pattern is consistent across every physical-AI deployment: one GPU node is easy, a thousand is an operation. In between sit the problems nobody budgets for: software and model versions drifting apart, application rollout, secrets, certificates, monitoring, rollbacks, compliance, and sites that lose their link and must keep running anyway. Containers solved packaging; they did not solve operations.

Avassa is the edge platform layer that does six jobs across that fleet: application lifecycle, infrastructure lifecycle, security, fleet management, disconnected operation, and automation.

While Avassa is not targeting to life-cycle your devices, the platform supports device discovery and mounting them to your container application.