Continuing with my model-and-event-driven service automation theme, some of you wondered whether I could dig a little deeper into how state/event processes were hosted, and also why ExperiaSphere mandated the separation of “orchestration” into a service and resource layer. This also gets into how federation of services across provider boundaries (or across administratively separate parts of the same provider) would work. I reference my general description of the architecture HERE. I don’t plan to take these issues deeper in blogs unless there’s a new development, but feel free to ask questions on LinkedIn!
The presumptions I’ve consistently made in modeling are that service models should be infrastructure-independent and that each model element be a “black box” or intent model. You’ll recall that a model element, when “decomposed” could yield either other model elements (a hierarchy) or an atomic commitment of resources. You may also recall that a given model element could decompose selectively, meaning it would yield different sub-components (either hierarchical model elements or resource commitments) depending on things like where the service was delivered or what parameters were provided in the order.
An example of a selective decomposition is where something like a cloud-hosted firewall, a uCPE-hosted firewall, or a firewall appliance might be selected depending on the service order. All these options are resource-specific, which means that if we allowed a “service model” to contain them, the model would be brittle because changes in hardware options might change how the model had to describe the decomposition to the resource level.
My solution to this was to say that the decomposition into resources was never part of a service model, but rather a part of a resource layer. The service model would then say (essentially) “I need a firewall in Oshkosh” and an Oshkosh-specific resource-layer model would then undertake to fulfill that need based on the parameters and what was locally available. Since what the service layer asks for in this example is a binding to resources, I’ve said that the resource layer asserts behaviors that are abstract functional properties, and these are then linked to requests for those behaviors in service models. There are a number of benefits to this approach.
First and most obvious, this lets service models stay functional in nature, immune to changes in infrastructure that could otherwise require that models be reformed when technologies evolve. The service model at the bottom of a hierarchy would bind to a behavior in each area where it needed resources. Oshkosh, in my example, is a location where customer access is needed and therefore where a firewall is needed. Whatever firewall options are available in Oshkosh are then candidates for selection.
A less obvious point is that if the resource layer and the service layer are connected only by a binding to a behavior, anyone could own the resources a service called on, as long as they exposed the proper behavior. That makes this process “self-federating”, meaning that you don’t have to do anything special to cross a provider/administrative boundary other than what you always do, which is to support service/behavior binding.
A further benefit of this model is that because the resource layer exports the behavior from an intent-modeled object that then decomposes to the correct resource commitments, the resource details are hidden and the only thing the service layer sees is the SLA and parameters. That’s what a wholesale/retail relationship requires.
There’s still more. If something breaks in the implementation of a bound resource behavior, the service layer could simply re-bind the resource, which would redeploy things and presumably select something that works. Further related to things breaking, the process of relating actual infrastructure conditions to the state/event processes of a model only happens within the resource layer; the service layer only operates on events generated by other intent-modeled service elements or on the events generated by the model element that represents the bound resources.
This approach to resources and Behaviors could also put some service-specific teeth into the notion of intent-modeled infrastructure. You can model resource behavior in hierarchical layers too, so it would be perfectly reasonable to declare some Behaviors associated with hosting, for example. These Behaviors could then be satisfied by intent models for cloud, container, and different implementations of both. Even bare metal would be a reasonable option.
My final point on separating services and resources in modeling is the benefit this can bring to securing the service lifecycle processes themselves. Resource commitments are likely to include data-plane connections, which must be in an address space visible to the user. In addition, many of the management interfaces and tools designed for either network or server elements are visible in the data plane. It’s desirable to keep the data plane isolated from the management/control plane of our lifecycle processes for security reasons, and it’s easier to do that if the service portion is separated in a different address space. Control/resource separation facilitates that.
The fact that service models and resource models are independent doesn’t mean that they couldn’t be orchestrated by common Factory processes where the functionality was the same, or even share state/event processes. The point is to isolate to the extent that isolation is valuable.
Let’s look now at the nature and implementation of state/event processes, which is where the lifecycle logic resides. The general model I used in ExperiaSphere was that the entire service data model (either service or resource) would be passed to any referenced process. This could be done by passing the actual data structure, or by passing a reference to the model in the repository. The process needs to know the object it’s being invoked on and the data associated with that object and nothing else, so it would be possible to pass only that, but it raises the question of synchronization should several processes be operating on the model at the same time.
The process itself would surely be represented in the data model as a URI (Universal Resource Indicator, the general case of the familiar URL), and the only requirement would be that the referenced process be visible in the network address space of the Factory that’s invoking it. My vision was that there would be a “Factory address space” where all the service factories and related processes were hosted, but you could segment this by service or any other useful means, subject only to the fact that this might restrict the reuse of common processes.
The processes themselves could in theory be hosted anywhere, at least for those referenced in a service model. Resource processes might be best hosted in proximity to the resources themselves, which is why I took the view that each “hosting domain” or “cluster” of servers would likely have its own Service Factory (or Factories) and would host the appropriate lifecycle processes for the Behaviors it hosted and the models it decomposed. Remember that a Factory is general logic to parse a model; the service lifecycle processes are just referenced in the model and invoked by the Factory as appropriate. In theory, both Factories and processes could be totally stateless and thus scalable and resilient.
This again raises the point of addressing and address spaces, a topic I think we’ve underthought in looking at modern virtualized or partially virtualized service infrastructure. Everything that communicates has to be addressed, and the address space of the service itself, the data plane, also has to be considered. If traditional management APIs are to be supported, they have to be connected.
I think the easiest way to think of a service is to think of it as a private subnet that contains the actual service-specific resources, much like the way a container-based application is deployed. Addresses within that subnet are then selectively exposed to a broader space, which might be the service data plane or the service lifecycle process (the resource layer) plane. Many models are possible, but we need to structure things the same way or we’ll have diverse implementations that require diversions in lifecycle practices, and that will make universal management much more difficult.
For those who want to dig deeper into the modeling, there’s a whole series of tutorial slides on the ExperiaSphere website. I recommend you view the annotated version of the presentations where they’re provided, because the notes per slide are helpful. As I said above, I’m not going to pursue these points further in a blog unless (as I hope there will be!) there are new developments in the space.