I bet a lot of people who hear that computing is moving to the edge, and that edge computing will be bigger than cloud computing, wonder how this squares with the fact that the cloud was supposed to be about server consolidation. Is the edge then the breakup of the cloud? All the new acronyms, like SASE and MEC, don’t help either; they add to our already daunting list. Then there’s the ever-present risk that this is all a hype game and we’re wasting our time. What’s happening, if anything, at the edge?
Edge computing has two drivers, and these happen to align with the two acronyms I used above. One driver is a change in enterprise network needs, driven in part by IoT and in part by the diffusion of workers created by the pandemic. The other driver is the architecture of 5G networks, and the fact that many of the hoped-for new revenue sources for 5G are linked to low-latency applications, also including IoT. Since IoT is common to both drivers, it’s a logical place to start our edge considerations.
IoT: So Much Starts Here
Most IoT applications are made up of a series of sensors and controllers connected to a local hub, which provides some direct control elements and some pathways for IoT information to enter into enterprise IT applications. Those of you who have home control systems have something like this in play; your security sensors, lights, and alarm sirens are connected to a hub that performs simple tasks based on sensor signals or time of day, and you can control it all from your smartphone.
Industrial IoT applications are more demanding because they often control movement of goods and parts that must be tightly synchronized with each other and with human processes. If you have a car door rushing toward the frame to be attached, it would be nice if the door and frame got to their intersection point at the same (and right) time. That’s where the latency stuff comes in. Mobile edge computing (MEC) is a model to provide edge-of-network hosting for latency-sensitive 5G IoT applications.
Industrial IoT applications are also likely to generate transactions, and that’s where SASE comes along. IoT systems are a new element that can present security problems to both homes and businesses. We hear about hacks of home control components every day, and of course business IoT is also vulnerable. It would help security a lot if we could create a secure access service edge (which, you guessed it, is what SASE stands for) that could ensure that a given location’s traffic, including IoT transactions, got to the right applications with the right priority, without risk of exposing the applications to new hacking exploit.
Both MEC and SASE have non-IoT dimensions. For MEC, the components of 5G networks themselves — the control-plane elements of the 3GPP 5G standards — are at least somewhat delay-sensitive, so they need low-latency hosting, meaning hosting near the 5G edge. SASE is valuable not only for IoT but for work from home (WFH), and simply to standardize and enhance the security of user access to applications.
This edge computing thing seems to have a lot of drivers, right? Well, the problem is that we already have a lot of IoT installations that don’t involve edge computing. We have mobile networks, even for IoT, that don’t use 5G or MEC. Since the whole SASE idea is fairly recent, it’s fair to say that we’ve evolved a pretty rich enterprise IT architecture without the benefits of SASE. Thus, SASE and MEC are examples of something that could open new applications and capabilities, but that depend on a clear business value for those new things before they’re really needed.
What’s the Value?
In the case of MEC, it seems certain that its real driver is the deployment of 5G, the use of MEC facilities by the 5G network rather than its users. We’re seeing a growing competitive tension between the cloud providers that want to host 5G elements and the cloud software vendors that want operators to build their own 5G feature hosting resources. Since the edge of the 5G network pretty much has to be in network operator facilities, whichever one gets the job of hosting will end up putting resources in telco central offices, and once there, those facilities could be used for latency-sensitive applications, including IoT.
For SASE, the near-term driver is probably operations’ consistency and efficiency. Branch office networks have gotten really complicated, and many are too small to be given MPLS VPN connections. SD-WAN interest exploded as a result, and with it, locations too small to have any technical support on site got joined to the company VPN. These sites had to be secured, and so security plus SD-WAN arguably created SASE. But SASE, like MEC, will provide IoT benefits when it deploys.
An IoT sensor/controller network is the ultimate too-small site; there might not even be a worker there to inspect and supervise. More and more monitoring and automated diagnostics are being considered for SASE to address not only the low-technology branches and WFH homes, but also the no-technology IoT facilities.
The point here is that we are moving applications to the edge, because we’re moving the edge itself. Networks that used to connect branches to data centers now connect users and IoT elements to each other, as well as data centers, and also have to connect data centers and users to the cloud. Network users are spreading out, and with that spreading, there’s some risk that hauling traffic to a single hosting point a thousand miles away will create too much delay. Edge computing is the byproduct of edge expansion, and so even if it doesn’t take over the mantle of the cloud as tomorrow’s technology, it’s here to stay… in some form or another.
