What Are Intent Engines Anyway?

We discussed earlier that intent engines are a class of declarative orchestrators that allow customers to use policy expressions to specify the services to be orchestrated. This classification does a nice job of distinguishing intent engines from model-driven orchestrators, but is it sufficient to fully define intent engines? Specifically, can all policy-based orchestrators be classified as intent engines?

To answer that question, we need to take a closer look at classification of policy expressions themselves. Policies can generally be classified according to at least the following two dimensions:

• Policies can be imperative or declarative
• Policies can be specified at different levels of abstraction

Imperative vs. Declarative Policies

Imperative policies expect policy expressions to specify actions that need to be taken by the policy engine in order to maintain compliance with the policy. Imperative policy statements are typically expressed using an Event-Condition-Action (ECA) pattern: if a certain event occurs, and the specified conditions are met, then take the following actions.

Declarative policies, on the other hand, focus on expected outcome rather than on the actions required to achieve that outcome. Declarative policies are typically expressed using a Context-Capability-Constraint (CCC) pattern: within the specified context, make sure that capabilities exposed by the system comply with the given constraints at all times.

Given that we have previously defined intent engines as a class of declarative orchestrator, it should come as no surprise that intent engines use declarative rather than imperative policies. As with other declarative systems, declarative policies are simpler to construct while leaving the complexities of the ensuring compliance with the policy to the orchestrator.

Level of Abstraction

The other dimension along which policies can be classified is level of abstraction. John Strassner’s policy continuum lists the following example levels of abstraction

• The business view expresses services and policies in terms of business goals
• The system view describes the architectural components of the service
• The administrator view specifies technologies used for each of the architectural components
• The device view lists device-specific configurations
• The instance view captures configurations of each instance

From the early ONF work on Intent NBIs (as described in their Intent Definition whitepaper), it is clear that the original goal of intent NBIs was to let customers express services using terminology that expresses business goals rather than technology details. This would imply that policies capturing intent should be expressed at the Business View level of abstraction. As specified in the ONF document, this presumes some type of mapping service that translates “intent” expressions into software-consumable constructs. This mapping is one of the primary functions that has to be performed by the intent engine.

Based on this analysis, we now have a better definition for intent engines: intent engines are a class of declarative orchestrators that allow customers to specify desired services using declarative policies that express business goals.

I’ll explore next how this definition can help guide us in the implementation of intent engines.