What is cloud-native about 5G and why is it considered edge? Overlapping terminology used by telecoms and cloud providers creates a deal of confusion, although the lines separating these technologies are fairly clear. In essence, we’re talking about three distinct technological concepts. It’s worth breaking these down, considering what they bring, and understanding the current status of edge before making a decision on how to use them.
5G is, straightforwardly, the next step up from 4G. The differentiator compared to previous generations is that it is based on IP, so you don’t need to have a dedicated mobile network infrastructure. You can talk over IP, use your data over IP, you don’t have any funky telecoms protocols. Despite the marketing hype about offering 5G coverage in the widest of areas, mobile operators are still replacing the core infrastructure to support 5G. This means that even if you go through a 5G tower, the backhaul can still be bottlenecked by 4G rates. So, we need to replace the whole core infrastructure. This is important, and has to do with the cloud-native part of it, which I’ll cover later.
The cloud, which doesn’t have anything specific to do with communication protocols, is just where you can process data. It’s useful to reframe the highly abstract notion of ‘cloud’ to the more tangible ‘outsourced infrastructure services’. Household names such as AWS, Microsoft or Google have a global datacenter footprint, but smaller cloud or colocation providers can also ensure you are in relative geographical proximity to your outsourced infrastructure services.
Mobile Edge Compute (MEC) takes the concept of cloud and moves it closer to a mast on the radio. So rather than having compute, memory, and storage in the data center, you can have them either with the radio mast, or somewhere very close behind. If you have a device that connects to a 5G network, you can do the processing right there and then, and get an immediate response. You don’t have to travel all the way to say Arizona, where AWS has many of its data centers.
To define Edge in terms of practicality rather than technical jargon, I consider it to concern any workload processed in an under 20 milliseconds round trip. So if I send a ping now, I expect it back in 20ms from where it has been processed. The reason for this criterion is that anything over 20ms, you can start to feel the delay. So, if you want to operate something in real-time and remotely, let’s say play in a distributed rock band, or do remote surgery, anything over 20ms feels awkward (and potentially risky) to work with. Similarly, if you have more than 20ms on your favorite first-person shooter game, you are going to be at a disadvantage compared to someone who has less latency.
Within this definition, the edge can be anywhere and anything. It can be a cloud, your own closet running Windows Server 2003, or, as you may have guessed, a radio mast. The whole appeal of characterizing 5G (which is more about radio access networks (RAN)) as edge, is that you’ve got almost ubiquitous coverage, with most people having even a dozen of these in a three-mile/five-kilometer radius around them. It’s also wireless, and now it’s IP-based. This is the foundation of multi-access edge compute (MEC), which is essentially edge workloads via 5G RAN.
As well as latency, there are questions around large volume data movements. If a retailer wants to scan a video stream for theft-related activity, it may not be cost effective to move the entire stream into the cloud and process it there. Better perhaps is to put the processing in-store or at the edge, but this will have a trade-off in terms of power usage, security measures and so on. So, do you run a microservice at the edge, or on a server in the cloud? Or, do you put the microservice on an end-user device, if it is powerful enough?
Earlier, I mentioned that 5G is IP-based. This is the cloud-native element of it – network functions and services (such as network slicing) are no longer dedicated appliances, but rather virtual appliances which run as microservices and in containers. That means that a mobile operator can join the rest of the world to spin up an AWS EC2 and run their network functions there. While this makes MNOs cooler and brings them in-line with the DevOps and NetDevOps folks, it creates its own challenges in terms of skills – service providers don’t have all the background or experience they need to build these networks.
Coupled with this, there’s not yet a standardized architecture for how MEC should look. Or, at least, I’ve not seen or heard of any universally agreed way of doing it. It’s more client driven – if you get a large enterprise that has say a 20 million budget for a deployment, they’ll do whatever they can to get that through the door. Is it going to be a standardized way, or are they going to do things a different way for other clients?
Unsurprisingly then, it’s very early days for MEC. Sometime in 2021, when I was working for a service provider, they were doing very early proof of concept deployments with some customers, for example drone detection for airports. This is still not something that gets rolled out on a regular basis, so it’s pretty much by exception at the moment.
There’s also too much focus on geographical proximity, and not enough on latency. A little measurement that will be useful, is that for every 500 miles (800 KM), the roundtrip is roughly 12ms. Having a radio mast in your backyard, or a CDN server in a neighboring city will make little difference. The differences come from network congestion, dedicated lines, wired or wireless connectivity, SLAs, and a nice and intuitive front-end.
It’s worth reiterating that Edge is a means to an end. I see a lot of parallels between marketing edge compute, and thinking of use cases for a brick. Sure, I can use a brick to stop my car from rolling downhill when parked, but there may be a better way of doing it. Maybe I can have a 5G-enabled car whose accelerometer’s data feed is streamed to a container that runs on a mast which engages the brakes when the car is not in motion and the plane incline is greater than two degrees.
The most common edge compute use cases I see today are website delivery or web experience, which take the form of the waiting room you join when buying concert tickets. Investing in cloud-native 5G-based MEC solutions requires careful planning for use cases which cannot be fulfilled by other technologies. Otherwise, the ‘do nothing’ option is good. Little first-mover advantage exists at this stage and the technology will continue to evolve.
You can read more about GigaOm’s research on Edge here.
The post <strong>How to Differentiate Between Edge, Cloud, and 5G</strong> appeared first on GigaOm.
