Last week, I blogged a series on the evolution of network and edge-hosted services, SD-WAN, SASE, and NaaS. I proposed that the edge platform of the future be based on a “metaverse of things”, and that the way MoT would likely develop would be as a set of layers. Today, I want to look at how those layers might look and how the evolution to MoT might occur.
The presumption behind this is that a metaverse is by its very nature distributed. Software would have to be hosted in multiple physical resource pools (the edge computing resources deployed in metro areas, likely) and that the pools would have to be connected in both a physical/transport sense and a virtual sense. Since the common requirement for edge applications is latency sensitivity, all of this would have to be accomplished without creating unnecessary transit delays for events/messages.
The software model for MoT would have to support, at the low level, this distribution of components, but at the higher MoT-logic level, the connectivity among them and the management of the exchange between the avatars that represent people or objects, and their real-world counterparts. This would have to be done via abstractions because different functions at different levels need to be implemented independently, something that was a fixture in the OSI model of layered protocols in the 1970s, and is the basis of “intent modeling” today. The logic would also have to fit the needs of the three major classifications of MoT applications.
The first class of applications would be the “Meta-metaverse” applications, the applications that Meta/Facebook envisioned, and that are represented today by massively multi-player gaming. I believe this model would define a metaverse as a series of locales, places where avatars and the associated real-world elements congregate and interact. A given avatar/human would “see” the locale they were in, and so each locale would likely have a virtual agent process somewhere, and that process would collect the avatar-synchronizing data for all the stuff in it. This model is avatar-focused in that the goal is to create a virtual framework for each inhabitant/avatar and represent that framework faithfully to everyone in the locale of the focused inhabitant.
The second class of applications would be the IoT applications. These applications could have a variable way of creating a focus. Industrial IoT, for example, would be process-focused where the locales and most of what made them up were static, but that some “goods avatars” might migrate in and out. Transport IoT might focus on a particular shipment, a particular conveyance, or even a particular item. The latency sensitivity of IoT applications would also vary, depending on control-loop requirements. Process-focused industrial IoT would likely need lower latencies than transport IoT, for example.
The third class of applications would be network-function oriented, meaning things like 5G and O-RAN hosting. These would be topology-focused, which I think is closely related to the process focus of some IoT. A network is typically made up of domains that are to an extent black boxes; they assert properties to other domains but not configuration details. Inside a domain you’d need to represent the physical reality of the network, which in most cases is determined by the real trunk configuration and the location of any static elements, such as the stuff the trunks connect to and any “real” (as opposed to hosted) devices/appliances like switches and routers.
MoT “middleware” would have to support all these application classes, but to try to do that by directly invoking low-level cloud or edge resources would tend to make the implementations brittle; any change to those low-level resources would have to be accommodated at the application-middleware level. This would require a three-layer model, with it likely that some of these major layers would themselves be subdivided to optimize the agility of the implementations.
The bottom level of this model would be the “platform” level, which would be the resources, the resource virtualization (VM, container) layer, and orchestration. Wherever possible, this layer should be supported using standard cloud and virtualization tools and software, because we’d want to exploit the technology already in use rather than have to create a new framework. However, it might be useful to assume that there was a kind of “shim” introduced to frame the resources of the platform layer options in a consistent way, which is part of the Apache Mesos cloud concept. Call it an intent-model overlay on the legacy platform options.
The top level of the model would be the MoT middleware, exposing APIs that supported building the three application models described, and perhaps others as well. It might be possible to build a generalized top-level MoT model-based implementation, something that could turn a hierarchical object model of an application into something that could be executed.
The middle level? This is something that’s a fairly new and not-at-all-obvious piece, IMHO. Applications today may be dynamic in the sense that they’re scalable and can redeploy in response to failure, and they may have requirements and constraints that would limit how they’re mapped to resources. Things like Kubernetes or a DevOps tool would deploy them based on these parameters. In an MoT application, the relationship between software and the real world, and thus the relationship between software components, is much more dynamic. There are more constraints to deployment and redeployment and to scaling, and since these processes could occur much more often, there’s a greater need to be able to tune things precisely. The middle layer of this structure is what has to do that.
The middle layer also has to perform a critical role in that abstraction process. We can’t have resource-level abstractions directly consumed at the application (top) level, or we would be inviting different implementations for each of our application models. The middle layer has to present the applications with a true MoT PaaS API set, so that applications can be written without any knowledge of the means whereby they’re distributed or how the elements within the applications communicate.
It’s my view that edge computing’s success depends on defining these three layers in as generalized a way as possible, so that all possible MoT models can be implemented without creating the kind of linkage between top-level application behavior and low-level resources that makes for brittle applications and silos. Development of edge applications is either very different from today’s development because of the special needs of edge applications, or there’s no real need for the edge to start with.
The challenge in doing that is the multiplicity of application models that make it important in the first place. Innovation tends to happen because of new players, especially startups. For decades, VCs who find these companies have been adamant that the recipients of their funding be “laser focused”, and avoid “boiling the ocean”. This is VC-talk to mean that they want their companies to find a very specific niche and play there. MoT and many other modern technology advances depend on developing a framework, an overall architectural model, to define all the essential pieces. Who does that in a laser-focused community?
What’s likely to happen instead is that we’ll build upward from my bottom layer, as MoT-like issues are raised by traditional compute and network evolution. The middle layer itself may end up being implemented as two “sub-layers”. The first would deal with the way that abstracted infrastructure can be harnessed for dynamic component deployment based on application logic, a significant shift from today’s component orchestration, which would introduce dynamism only in response to scaling or failover. This is essential if MoT logic reconfigures itself in response to things like avatar movement. The second layer would then create an abstract set of “metaverse services” that would host and connect things in a totally implementation-insensitive (but constraint-aware) way.
We have at least one example of the first of these sub-layers already, and that’s what I’ll talk about in my next blog.
