It seems to me that if you read the tea leaves of current carrier plans you see that the potential for new things like SDN and NFV are being inhibited by “old-think”. If we try to build a new model of a Carrier Ethernet network, we’re limited in the benefits we can bring relative to the original model. But businesses network sites not people, and we have established business communications, application usage, and collaboration practices based on the old network model. If benefits come from above, then these three high-level things are going to have to change for us to get the most out of a new network technology down below.
The big mistake we make in thinking about the future is looking at it through a lens of limitations. I can still read Hollerith card codes, and I remember “batch processing”. That’s fine as long as I don’t cast the limits of those days into consideration of today and tomorrow. But the past does provide us with an opportunity to take a fresh view of things too. We didn’t always have IT, business or personal networking. How did we evolve from nothing to something? Part of it involved making IT into a real-time work partner or life partner. But how exactly does that happen?
The answer in my view lies in a fundamental truth about people, perhaps a truth profound enough to be one of the criteria for humanity. We are contextual beings. What makes human thought a powerful tool is that we interpret things as a whole, in context. We see conditions, we see stimulation, we see possible future outcomes and risks, and we decide.
In the early days of IT the worker and the computer were not partners; in many cases the worker never interacted with computers at all, even where some IT applications were in place. People used computers to record what had been done, and so in a sense we had big data applications before we had “little data” because the goal of early applications tended to be more analytic than productivity support. To make productivity support better, we brought the IT processes closer—meaning we made the IT processes contextual partners.
IoT is forcing us to look at this contextualness thing more closely, because what IoT would really do is allow applications to absorb more context without troubling humans to provide it. If I can use IoT to know when I’m looking at the right panel in a factory, I don’t need human processes to do that and those human processes are then relieved of a task that inhibits doing the work.
I’ve blogged about IoT and context from a network perspective, a cloud perspective. There’s another question beyond that, which is whether we may have reached a point where what we need to have is contextual IT rather than trying to fit IT into a context. If humans like context, if human work and entertainment is increasingly contextual, why not deliver context-as-a-service?
Suppose you’re strolling down the avenue taking some air and getting some exercise. How are you different from an alter ego that’s looking to buy a gift or trying to find the location of a meeting you’re late to? Same you, same avenue, same stroll, but different context. This doesn’t seem important when you think about your stroll in traditional terms because you know what you’re trying to do, but you can see that personal or business services directed at you would have to be different for the three missions, or they’d be irrelevant at best and intrusive at worst.
If we had contextual processes inside our network, we could accept a general mission from you and then build an appropriate context around what you are doing and what the partner processes are doing for you. If you’re strolling, the process could point out interesting byways or diversions, points of interest. If you’re shopping the processes could direct you on a route that passes the largest number of suitable retailers, or the lowest prices. If you’re looking for a business meeting, of course, you want to get guidance on the fastest path, including when to cross over to maximize the timing of traffic lights. Network services, IoT or beyond, have to do what’s useful.
There are a lot of challenges to contextual partnership, though. To start off, you have to decide whether you are adopting a “pull” or “push” model, meaning whether the user being supported, directly or inferentially because of the mission, ask for information from the service, or whether the service pushes information at the user. Obviously, the more the user has to do the less incrementally useful the service is. Why not just give them a search engine? So we either have to anticipate user needs based on something, or push events and then policy-filter them to insure we’re not intrusive.
Calling, viewing videos, shopping, and many other things can now be cast as context-management activities. Personal communications already divides logically into what could be called “chats” and what could be called “collaboration”. A chat is an event, but a collaboration is a sharing of context.
All of this argues strongly for an agent in the cloud, a context partnership that’s valuable in part because it’s explicit. The user, out for a stroll/buy/meeting, tells the phone/partner what is happening. The partner process then proceeds to stimulate and filter as appropriate, via the phone. The intermediary partner unloads the enormous data load associated with maintaining context and also provides security and privacy.
The obvious consequences of this approach are a significant increase in cloud-hosted applications as elements of a service. This isn’t as much an NFV process as it is a multi-tenant server process, though it may be useful to employ NFV to scale some components and even to instantiate those partner/agent processes as needed. There’s also a need for a lot more intra-cloud bandwidth to insure you don’t tell someone to cross to make a light thirty seconds after it changed. There are more impacts, but to consider them we first have to look more at those contextual-partner processes.
I mentioned in a prior blog that the logical consequence of software-agent-based web activity would be an explosion in microservices, each designed to provide (in our example here) an element of contextual information, contextual filtering of events, etc. The satisfaction of contextual requirements seems to demand something that almost looks like dynamic service composition. NFV postulates the creation of services by the assembly of functions, but the associations are presumed persistent. With contextual processing it would appear these associations would have to be ad hoc, almost momentary.
This raises an interesting question, which is whether agile service management principles for NFV could—if properly extended—become agile service logic principles. Is contextual processing a kind of self-authoring application where the high-level model is set by the “context goal” and the rest is optimized based on conditions? If so it’s a mixture of analytics, complex event processing, flow machines, and more.
I think it’s inescapable that context-partner applications and the microservices that support them will rise sharply. Not only are they driven by mobility, they’re also driven by IoT and by corporate interest in harnessing the next wave of tech-driven productivity improvement (which they’ve awaited for 15 years now!). Those changes will, of course, drive changes in networking—not so much in spending on infrastructure as in where the money goes. Access is still essential, but IP backbone could be reduced to accommodate greater emphasis on metro intra-cloud applications for context processing. It could generate a more SDN-ish mission, which would tend to accelerate operator plans for SDN—plans I’ll be blogging about next week.
