Abstract Service Models and the Model Continuum

From the classification introduced earlier, we know that model-driven and policy-based orchestrators both fall in the category of declarative orchestrators. Model-driven approaches describe services to be orchestrated using service models that represent service topologies, whereas policy-based approaches describe the services to be orchestrated in terms of expected service behaviors and/or outcomes.

Policy-based orchestrators tend to provide simpler interfaces than model-driven orchestrators, since they expect less detail from service designers. Whereas model-driven approaches expect entire service models, policy-based approaches expect declarative policies that express constraints on observable parameters (“capabilities”) of the deployed service (the “context”). Context, capabilities, and constraints are all that is needed for declarative policies.

Policy-based orchestrators appear to have the added advantage that (declarative) policies can be expressed at various levels of abstraction in a policy continuum. This leads to the concept of intent, which refers to declarative policies expressed in terms of business goals.

However, we should ask ourselves if that advantage really only applies to policies, or whether model-driven orchestration can benefit from abstraction as well? The answer is obviously yes, since abstraction is at the core of almost everything we do in software engineering. In fact, a model is in essence nothing more than an abstract representation of the actual entity that is being modeled. If models are (almost by definition) abstract, then clearly we should be able to create different types of models depending on the level of abstraction at which we’re trying to model. Allowing users to model services at a high level of abstraction would simplify the task of the service designer, similar to how intent engines simplify the challenge of creating declarative policies.

This observation leads to an obvious parallel between models and policies: if policies can be expressed at different levels of abstraction in a policy continuum, then it should be equally possible to create models at different levels of abstraction in a model continuum. The following example levels of abstraction could be used in a model continuum: 

• The business view describes services as products that are available to customers
• The system view describes the system architectural of the service
• The administrator view specifies technologies used for each of the components in the system architecture
• The device view lists specific software modules and/or resource configurations for all of the components of the service
• The instance view captures configurations of each instance

Granted, most model-driven orchestration systems today don’t fully support these levels of abstraction. They expect users to provide service templates that sit at the device view level and can best be described as deployment descriptors: low-level representations of the actual software components to be deployed, coupled with the resource configurations that are required to host those software components. But if intent engines can be expected to have the smarts to map high-level business goals into deployable services, wouldn’t it be reasonable to also expect model-driven orchestrators to be sophisticated enough to translate abstract service models into low-level deployment descriptors? I plan to explore later how such translation could be constructed.