Intent Engines and Orchestrators

Intent is increasingly being positioned as the appropriate paradigm for network and service orchestration, and for good reason since the intent paradigm significantly reduces complexity for service designers. Consumers of intent-based systems can use simple intent statements to express their expectations for the service, while leaving the details (and the associated complexity) of how to meet those expectations up to the service provider. In other words, intent focuses on the WHAT, not on the HOW.

Systems that adopt an intent paradigm are typically referred to as intent engines. Intent engines are orchestrators that map simple intent expressions into the resource allocations and configuration parameters that are required to deliver on the intent.

To understand how intent engines relate to other types of orchestration systems, it is helpful to review the traditional distinction between imperative and declarative orchestrators:

• Imperative orchestrators focus on the HOW: users of imperative orchestrators are expected to tell the orchestrator exactly how to get services deployed by prescribing the exact set of actions the orchestrator needs to take. Traditional automation techniques (e.g. “infrastructure as code”) are an example of this approach.
• Declarative orchestrators focus on the WHAT: users of declarative orchestrators are expected to describe what it is that they’re trying to get deployed and leave it up to the orchestrator to use the appropriate mechanisms to get a service deployed that delivers “WHAT” is expected.

Based on this classification, intent engines are clearly declarative orchestrators, given their focus on WHAT. But is it fair to assume then that all declarative orchestrators are also intent engines? To answer that question, we need to take a closer look at what exactly can be meant by WHAT:

1. In one interpretation, WHAT can refer to “what things look like”. This is the STRUCTURAL point of view. Declarative orchestrators that use a structural approach expect service designers to describe the service topology that contains the entities that make up the service and the relationships between those entities.
2. On the other hand, WHAT can also refer to “what things are supposed to do”.  This is the FUNCTIONAL point of view. Declarative orchestrators that use a functional approach expect service designers to describe expected behavior of a service or expected outcomes to be delivered by the service.

These two different categories tend to use entirely different technologies to describe what is expected:

1. Structure is typically described using service models—information models that describe a service as a set of components and their relationships. Declarative orchestrators that process service models can be referred to as model-driven orchestrators. 
2. Behavior is typically described using policies that describe observable parameters of the service and the constraints with which these parameters have to comply. Declarative orchestrators that process policies can be referred to as policy-based orchestrators.

Using this classification, it should be clear then that intent engines fall in the functional category and are a type of policy-based system. While model-driven orchestrators and intent engines are both types of declarative orchestrators, they approach the problem from very different angles.

One could ask then, which approach is best. Answering that question requires a bit more analysis about how to construct policies that can capture intent, but it is safe to say that intent-based systems present a higher-level of abstraction than model-driven systems and as a result should be simpler to use. That said, I believe there is a clear synergy between intent-based and model-driven systems, which I hope to explore in more detail next.