In the two earlier blogs in this series on as-a-service and runtime modeling, I looked at how the lifecycle modeling of services could facilitate the handling of service events and support lifecycle automation. I then looked at expanding the modeling to include the orchestration of event-driven applications, and at how the two models could be integrated to improve application and service utility.
Paying for services (like paying for anything) is a higher priority for the seller than for the buyer, but buyers are interested in accounting for what they’ve been asked to pay for. Sellers are interested in cost accounting, profit management, and integrating third-party elements into their own service offerings. There’s obviously a commercial dimension to be considered here.
Let’s start by recapping (quickly) the approach to unified runtime and lifecycle modeling I advocated in the last two blogs. I suggested that the runtime model and the lifecycle model be connected by creating a parallel lifecycle element that was linked to each runtime element by an event exchange that was confined to a change in the in-service state. The runtime element and the lifecycle element would each be bound up in their own models as well, so there would be two model structures, bound by in-service event exchanges at the level of the runtime elements. If an event-driven application had a dozen component elements, then there would be a dozen parallel lifecycle model elements.
Commercial terms, in the TMF approach, are assigned to Customer-Facing Services (CFSs), which to me implies that a service element is always represented by a pairing of a CSF and a Resource-Facing Service or RFS, because obviously it’s the way a service is bound to resources that creates costs. This is logical in many ways, but to me it encourages rigid relationships between the CFS and RFS, and that might have negative consequences when it was necessary to replace a broken resource.
When I did my first, TMF-linked, ExperiaSphere project, I took a slightly different approach and suggested that the “resource domain” would advertise “behaviors” that were then bound at service setup to the “service domain”. This was to keep the service models from becoming specific to resources, something generally important but critical if some service components were to be acquired from third parties. Commercial terms, in my approach, were associated with the behaviors, and the dynamic binding could then consider commercial terms in selecting a resource set to fulfill service requirements.
If we could assume that commercial terms would always be associated with the committing of a service component to its corresponding service, we could make commercial terms management a part of lifecycle management, and it could be applied when the service lifecycle enters “in-service”. That would correspond to the way both the TMF and my first-generation ExperiaSphere worked, but it’s not a suitable solution to service elements that are usage-priced.
Usage pricing requires integration with the runtime event/information flows in order to determine usage. It would be highly undesirable to have usage information collected outside those flows, for performance and resource efficiency reasons, so we would have to assume that usage data would be collected by the runtime service element itself, or that it could be collected by counting events/messages directed to the element, as part of the workflow.
It seems to me that if it’s important to offer support for commercial terms collection and reporting, it would be better to include the collection of the usage data in the “middleware” associated with event/message flows, rather than trying to write it in to each of the processes in the flow. The latter allows for too much variation in approach, and redundant logic. The good news here, I think, is that we have a technology available to do the message statistics-gathering, and it’s already in use in related areas. It’s the Envoy sidecar.
In service mesh applications (including the top two, Istio and Linkerd) a sidecar is used to represent a process element in the mesh. Since the sidecar sees the traffic, it can count it, and in service mesh applications the results can be obtained from the service mesh element (Istio, Linkerd) if there is one. If there’s no current sidecar, then I think there’s ample reason to employ Envoy where it’s necessary to monitor usage and cost. We could obtain the data, and integrate it with overall commercial-terms management, using what I called in 2013 “derived operations”.
What derived operations says is that you obtain the status of something not by polling it directly, but by reading it from a database that’s populated by polling. This principle was considered by the IETF briefly (i2aex, or “infrastructure to application exposure”) as a means of providing application coupling to network MIBs, rather than having many applications polling the same MIB. If we assume that we have Envoy available for all our realtime processes, then we could say that either the lifecycle management or commercial terms data model included instructions to run a timer and collect the data (from Envoy or a service mesh) at a predetermined interval and use it to populate the data model.
If we assume that we have the “rate” price for a service element stored in either the commercial terms or lifecycle management data model, and the usage data is also stored there, we have all the information we need to calculate current costs while the service/application is active. If we are setting up the application, and if we can make selections of resources based on cost, we can use the “rate” prices to compare costs and pick what we like. Any references to the cost/price/usage would be made to the data model and not directly to the Envoy sidecar, service mesh, etc. That would decouple this from the specific implementation.
The question is whether you need to have a separate commercial model or if the lifecycle model could serve both purposes. I’m of the view that adding another model dimension would be justified only if there was a clear benefit to be had, and I’m unable to see one so far. I’d determined in ExperiaSphere that the state/event tables should include a timer to be started before the indicated process was run, and that the timer event should then be activated if the timer expired. This also means that there should be a “stop-timer” indicator in the table, so that suitable events could stop the timer. That allows the timer to be used to activate periodic statistical polling and store the result in the data model, so there’s already a timer available to exploit for polling.
Given all of this, it’s my view that collecting information associated with the commercial terms of a service/element, and creating price/cost data for either selection of components or for generation of bills or reconciliation, is best considered a function of the lifecycle model. Placed there, it matches the needs of those services that are not usage priced without any special accommodation; cost data is simply part of the model. For usage-priced services, the lifecycle model’s in-service state/event processes can include a timer that would, when it expired, indicate that the Envoy/service-mesh package should be polled for statistics, and they’d then also be stored in the lifecycle model.
All of this appears to be workable, but one big question is whether it’s valuable too. The service mesh technology developing for the cloud, combined with various deployment orchestration tools like Kubernetes, have the ability to manage deployment and lifecycle stages, including scaling, without a model. Edge computing might be supportable using just these tools, or it might not. It seems to me that it depends on what “edge computing” turns out to mean, and how 5G hosting might influence it. If edge services are created by composing “service atoms”, potentially from different sources and in different locations, then homogeneous development practices to exploit service mesh/orchestration tools will be more difficult to apply across the whole service, and the composing process will have to be modeled. If connection services and edge application services are combined, that same truth comes forward. We may not need a combined modeling strategy for networks and hosting everywhere, for everything, but we’re likely to need it in some places, and for some things. That makes it important to know how it could be done.