In our first test of Mastodon chats on podcasts, conducted on January 4th, I think that it would be fair to say that edge computing and its impact on tech spending was the big topic. Within that big tent, there seems to me to be two supports. One is just where “the edge” really should be. The further outward you go, the lower the efficiency and the greater the impact on sustainability. The other is what applications for the edge would need to have in the way of baseline “platform” services. Absent some middleware support at our hypothetical edge, it could become the grand and glorious mother of all silos.
I think most who follow my blogs know that I am not a subscriber to the “extreme edge” theory, of pushing edge hosting all the way out to the central office locations (roughly 14 thousand in the US) or even the cell towers. I favor the “metro” strategy, which would place edge hosting in population centers that could support low-latency connectivity to the access network, fixed and mobile. I’ve tried to model that placement, and come up with roughly 250 in the us and about two thousand worldwide. As I said on the Mastodon chat, the higher the overall demand density of a market area (like the US or any other country), the smaller the number of metro sites would likely be required for a given total population. Smaller area, fewer metro sites.
The thing about metro hosting as “the edge” is that the positive of greater efficiency depends on having a fairly universal hosting model. If you have to subdivide your metro pool of resources into five or six mission-specific segments, you lose economy of scale. At the same time, though, tech in general and hosting in particular normally achieves universality through loss of specificity of features. If you have six missions, then you pick a subset of all possible middleware features that can support all six, right?
The problem with that is that you still need some uniform feature set within each of those six missions, and if you don’t provide that in the edge platform, you invite every collection of applications within every mission to build their own tools, creating more silos than before. Further, there’s a pretty good chance that within those six (or whatever number you like) missions, there are some common requirements for groups of two or three, and maybe even a few common to them all. A lot of development time could be wasted and resource and operations efficiency could suffer.
Again citing our Mastodon toots, “contextual” or “point of activity” services represent a general class of features, and my view has been that we should consider the edge as a platform-as-a-service framework that supports that general class of features, and that offers guidance on how the general feature set could be augmented with mission-specific capabilities. In short, we need a PaaS that has an inclusive architectural model that encourages extensibility, and those two terms define what our model has to supply.
The thing that’s common across our two terms is the integration of a hosted service into the details of our work and lives. Both involve “activities”, and in order to integrate something with those activities, we need to understand our “context”, which means the frame of reference into which we are placing events, objects, people, and (yes) assisting technologies. The baseline requirement for our model, then, is an understanding of our context and our activities. Place us in a mission (activity) and locate us in the real world in all the dimensions that our senses can register.
When I take a walk (or, as some of my detractors might say, a totter), my phone will make an assessment of my movement, and finding it taking me away from my home location, it declares it to be a walk. Thus, my location is a key element in both context and activity identification. In fact, I believe that location is fundamental to our new model, and the more precise it is the better.
We can establish location through GPS, through triangulation of cell signals, through proximity sensing using multiple technologies, and so forth. It would be madness to assume that all applications that needed location would have to be aware of all the possible options and the technology required to access each of them. A “location service” that presents user location via an API would be the smart way to approach this. But what does that location service deliver? Location is abstractly latitude and longitude, which almost surely does little good for most applications. We really need to think about location the way my phone did on my walk/totter, and consider location relative to something. Context.
I have the option, with my phone, of starting an activity explicitly, in which case my phone knows exactly what I’m doing. One essential input to our process of activity identification is direct identification by the user/worker. It may not be meaningful in all cases to get the sort of precision that direct identification brings; if I’m walking around the neighborhood does it matter whether I’m walking to “clear my head”, for “exercise”, or whatever? But if I’m walking down a street in a town or city, it might matter a lot if I’m strolling, heading to lunch, or shopping. Why, because what I get in the way of information from contextual point-of-activity services would vary across those options.
If I’m shopping, I’m probably shopping for something. Suppose my contextual service knows what that something is, and suppose it can use that to inquire into the websites of the places I’m passing or likely to pass in order to determine if they have an item I’m looking for and how their price compares. But of course I may be strolling, and have a few items I’m just thinking of picking up. If I happen to pass a sale on one, couldn’t it be helpful for my service to alert me?
Useful services that support work or life have to know what you’re working on and how you’re living. In order to do that in a practical way, we have to define a general process of gathering information about context and activity and presenting it to an application set through a standard set of APIs. We can’t allow those APIs to be too low-level (like presenting location as latitude and longitude) or we’ll make development of contextual applications horrendously expensive, and hosting them an efficiency and operations mess. We need that PaaS.
And, of course, we need a business case, and that’s another part of the reason for a PaaS. You can’t expect applications to develop in anticipation of both a suitable hosting platform and a reasonable ROI. Everyone accepts that “edge” differs from “cloud” primarily in that the former distributes hosting closer to the point of activity in order to ensure that the contextual vision of the applications is closely synchronized with the real world. A PaaS model, designed to get something into play, justified by current applications like NFV or 5G, could support gradual introduction of contextual applications, paced at the speed of acceptance and generation of returns.
The point here is that context is complicated, and so are the processes of identifying and supporting activities. This is why I’ve come to believe that all contextual services would have to be supported using a digital twin modeling, which would make it in my view a form of a metaverse application. I don’t know how to think of the challenge of contextual or point-of-activity services in any other way, architecturally speaking. To expand on what I said in the last paragraph, you need a model of at least an abstract piece of the real world to help people live and work in it.