I’ve blogged quite a bit about management and orchestration and the management challenges of next-gen services. Connection services are largely defined by their management challenges, since they connect users and experiences rather than creating features themselves. When we look at more advanced services, leading up to the cloud and SaaS, it’s a different matter. For these services we have a kind of fork in the road—service management on one side and service logic on the other.
Most services have an architecture in a service logic sense, meaning that they have a model that describes how the features of the service, hosted somewhere, interact with each other, with the underlying connection services of the network, and with users. In most cases today, the logic and architecture are created by the relationships among the devices (switches, routers) that create the service. A service like the Internet, though, has a distinct service architecture because there are feature elements that support basic connection capabilities—things like DHCP, DNS, NAT—that fall outside the devices that push the bits. Service functionality may not be dead in its tracks because you’ve lost DNS and DHCP, but the average user of the Internet couldn’t get online or do anything there without them.
In the area of network services, we’re confronting the notion of a service architecture most directly in the evolution of NFV. The more you say that network functions, having been virtualized, now have to be instantiated and integrated in some way, the more at risk your service is to having some piece not working. When you deploy a series of virtual functions you use a MANO process to do it, but once deployed these functions create a service architecture that has to represent the functionality the user expects.
This also happens in componentized applications—classic “SOA” or service-oriented architecture. The “work” of the application is passed between components in some way, usually through some kind of service bus and perhaps mediated by something like BPEL. Components without workflow are just anarchy; they don’t add up to any cohesive, consistent, or even logical experience. Workflows are created by steering principles that the service architecture (in this case the application architecture) defines.
One of the questions this all raises is whether we need to have a service architecture template or framework for advanced componentized services of any sort. We might not have a single model of workflow for a componentized application, for example, but we do have standardized components from which all the workflows can be built. Such an architecture could define not only standard ways that components could relate to each other to do standard things (access LBS and social presence, for example) but also provide a framework to introduce management tools based on dependable principles.
All cooperative services need cooperation, and all componentized services, multi-stakeholder services, and composed/orchestrated services are cooperative. Right now, we leave it up to the component designers to frame interfaces, and that’s OK as long as we recognize that defining chapters in an arbitrary language means either imposing a burden on the reader to be multilingual or a burden of translations. A little order up front saves a lot of effort down the line.
Even at a basic level, though, service architecture issues are complex. Virtually all service processes have to be visualized as state/event activities (finite-state machines to purists) in that they are stateful because people are contextual, and they are event-processors because there’s a lot of stuff inside a service and linked with it as a user/resource that might end up demanding attention. The simplest model of a service architecture is the state/event table that associates handling instructions with each combination of service state and event.
But what about situations where you say “if I get this condition and that condition and maybe this additional thing all here, in close proximity, then I need to recognize that as being something special, something different? We have “Complex Event Processing” systems that look for that sort of thing, and these are particularly useful when we’re looking at a stream of stuff and trying to decode events out of the mess. Think of CEP as a kind of real-time correlative analytics, and if you use it right you can often simplify the state/event relationships by reducing the number of times you have to use states and events just to see if you really have a significant event in the first place. Our individual this-and-that combination would need states to decode; with CEP we might not need them.
This sounds complex, but not all services will have this kind of service architecture problem. It’s possible to visualize many mobile services as being brokered through the device app itself. It’s also possible to simplify the problem of coordinating activities in a complex system by having a series of “function-broker” elements that perform high-level tasks by invoking a more complicated set of underlying services. For example, imagine the hypothetical service “IsShopping” or “IsBusy”. We could call one with the identity of a user (“Tom”) and find out based on LBS, calling behavior, search or app activity, habits, and so forth what the probability of “Tom” being in the referenced state. Now we don’t have to orchestrate that complexity into an application.
But, of course, as Heinlein once said, “There’s no such thing as a free lunch”, meaning that disguising complexity with agency simply moves it into the agent. It does make a helpful point though, which is that as we move into advanced service architectures, we’re likely to find function hierarchies to be useful tools. Create abstractions that envelope stuff to help make the higher-level processes more agile with less effort.
You may see in this a similarity with service management too. I’ve advocated “orchestrating” management and deployment of services, and it just might be possible to think of service logic in the same way, composing workflows in the same way that we compose the service deployments or management processes. Unifying service logic and service management, at least in terms of creating a structural model that defines both and thus allows both to be derived from a single “picture” would be a help for all in an era where service complexity is likely to explode to the point where we’ll all need help.
