Declarative vs. Imperative Orchestrator Architectures

It is generally accepted that declarative orchestration is superior to imperative orchestration because declarative orchestrators let end-users focus on the WHAT, while leaving the complexities of the HOW to the orchestrator. Intent Models provide an excellent framework for declarative orchestration, since they combine both model-driven and policy-based orchestration, and they allow for mapping of high-level business goals into low-level deployment descriptors using recursive decomposition.

What hasn’t been widely explored is the impact of the chosen orchestration paradigm on the architecture of the orchestrator that implements that paradigm. As can be expected, declarative orchestrators tend to implement an architecture that is very different from than of imperative orchestrators. What may be a bit surprising, however, is how much simpler and how much more elegant declarative architectures can be as compared to the more traditional imperative architectures. The following table highlights some of the architectural differences between declarative and imperative architectures, and hopefully illustrates the simplicity of declarative architectures:

Declarative Architectures	Imperative Architectures
Organizing construct: recursive decomposition	Organizing construct: static layering
Arbitrary number of levels of recursion	Fixed number of layers
Flexible resource layer: no architectural distinction between resources and services; resources are accessed as services, and services can be exposed as resources	Inflexible resources layer: distinction between resource layer and services layer is baked into the architecture
Identical orchestration functionality at each level in the recursion	Layer-specific orchestration functionality
Interface paradigm based on negotiation (request/response) and delegation	Interface paradigm based on management (higher layers control lower layers)
Interface implementations based on Domain-Specific Language (DSL)	Interface implementations based on APIs
Identical DSL at each level in the recursion	Layer-specific APIs
Federation built-in: North-south and east-west interfaces are the same	Federation must be added-on: North-south and east-west interfaces are different

Unfortunately, the reference architectures that are currently most widely adopted in the industry (e.g. the ETSI NFV architecture and the MEF LSO architecture) are largely imperative architectures that impose a "legacy" layered view of the world.  Attempting to implement a declarative orchestration paradigm in a declarative architecture is like trying to fit a square peg in a round hole. It can be made to work, but likely with bloated implementations and lots of special-purpose code as a result. If we're serious about adopting declarative orchestration paradigms, we may want to go back to the drawing board when it comes to standard reference architectures.