With the exception of Cisco, none of the network equipment vendors can market themselves out of a paper bag. Juniper, perhaps, is even a bit worse than average. Their positioning of their Mist acquisition has been murky, but they’re apparently working to refine it now. The question is whether there is a real value proposition for an “AI edge”, and if so whether Juniper is actually moving toward realizing it.
SDxCentral wrote the latest Juniper move, “Mist Edge” up HERE. In effect, what Juniper is doing is extracting AI from the wireless management application Mist originally promoted, and moving it onto an appliance. This has the benefit of improving wireless management by reducing latency, but Juniper also says this will let enterprises rev up a distributed-microservice architecture on premises without having to move to the cloud. But is this really a useful AI-edge concept? To find out, we first have to look at the overall utility of an AI edge.
Intelligence is about drawing inferences from information, and so an AI function should do that. Since “information” into the network (as opposed to about the network, meaning network events) is the source of our inferences, it’s logical to presume that having AI close to the point where information enters would be helpful. Logical, of course, is often a bit of an oversimplification.
Drawing inferences is usually followed by acting on them. If you make an inference close to the information source, then send the inference a couple thousand miles to act on it, there’s not much lost if you move the inferring task to where the action is. The value of AI at the edge, then, is linked to the value of pushing control responses close to the edge, which is related to the need for managing latency in the control loop.
An edge appliance is very different from an edge server. There are software design patterns and middleware that let a “server” be a virtual element that fronts an entire data center or even a collection of data centers. An appliance is by nature a more locally focused element. If you had a cloud mission, you’d expect to deploy a cloud. If you have an appliance mission, you’d expect it to be more local. Yes, there could be a cloud architecture behind it, and this is true with Mist Edge because it’s a local instance of a cloud management function, but if the management function was in the cloud to start with and was then pushed out to an edge appliance, you’d have to presume that the reason was that there was local stuff to do.
What this means for an edge appliance concept is that it’s not “cloud equivalent”. There are limits to how much processing you can do in an appliance, so there’s a limit to how sophisticated a set of actions you could host to respond to your AI inferences. There are also limits to what Mist Edge might be able to do in terms of inferring stuff from various inputs; the material on that isn’t published yet and suggests that there’s still work being done there. That limits what we can infer about Mist Edge’s inference value, but we can lay out some rough issues.
With source information that fits fairly well within the parameters of WiFi 6 management, there’s little question that Mist Edge could do the job. That would be true for WiFi (obviously) but likely true for 5G-related cell-site management, and it could also be true for content delivery networking. All of these things could use AI based on conditions recognized and actioned locally without a whole lot of heavy lifting.
What falls outside that range of applications is more problematic, in part because we don’t know exactly where Juniper will take their Mist Edge concept and in part because the value of AI and the value of event-driven applications are both fuzzy when you consider the broad market—like IoT. There’s a good chance that you could fit Mist Edge into at least some IoT applications, but the problem is that Juniper so far is focusing (at least in their discussions with the media) the Mist Edge on the enterprise. Operators do 5G and operators are probably the best target for a Mist-Edge-like concept for IoT as well.
I’ve said in many past blogs that open sensors on the Internet are a loser in a business-case sense. The best way to exploit IoT sensors would be for someone to add an inference layer to them, both to digest raw sensor data to make it more useful and to protect sensors from hacking, spoofing, etc. Operators might use an appliance to make basic, local, inferences that would then be sold as services to OTTs or exploited by their own higher-level applications.
The big question here is what tools Juniper/Mist might be adding to the arsenal, and that’s hard to say. The Mist website talks about a “cloud architecture with microservices”, but the details on the site are all related to WiFi management: “The world is going cloud…Now wireless can too.” It’s probable that there’s an underlying architectural model behind any WiFi-specific features, but that architectural model isn’t presented in enough detail to evaluate.
There could be value to this concept, make no mistake. The value, I think, will depend on whether Juniper can push the details of the Mist Edge AI capabilities to areas not specific to WiFi, and perhaps not even specific to enterprises. It could then represent a truly, broadly, useful step for Juniper. Or it could be nothing more than AI-washing if Juniper can’t collateralize the details. I think it was a mistake for Juniper to push out the notion of a Mist Edge without creating and validating a broader mission than WiFi optimization. If they weren’t prepared to describe what utility they were aiming to achieve and how they were intending to realize it, they should have waited. It’s hard to relaunch something these days, and there could be real value here that’s at risk to being missed.