Delegation—A New Federation Paradigm

In cloud and NFV-based environments, services are deployed dynamically using orchestrators—logically centralized entities that manage and coordinate the life-cycles of the components that make up the service.

For services that fall entirely within a single administrative domain, one orchestrator can take responsibility for end-to-end setup of the service. However, many services are not limited to a single domain. For example, imagine enterprise users accessing a cloud service across an SD-WAN, with virtual CPE devices deployed at the WAN edge to protect the enterprise network. This type of end-to-end setup might involve components from three or more different administrative domains. Orchestrating such services requires cooperation between the orchestrators responsible for the different domains.

Traditionally, whenever cooperation is required between entities in different domains that provide the same (or equivalent) functionality, federation is proposed as the solution. Federation refers to pre-arranged peer-to-peer relationships between autonomous entities that allow them to share their information, resources, and functionality via well-defined protocols. When two service providers federate, customers from one provider have access to resources and information from the other provider and vice-versa—within the constraints of the rules established by the federation agreement. Federation typically involves a settlement arrangement that ensures that both parties are compensated appropriately for their respective contributions to the joint relationship.

Federation is an appropriate construct in a legacy world where:

• Services are monolithic: they contain the complete stack of consumer-facing functionality as well as all the necessary supporting components within a single package.
• Services use fixed layering: higher level functionality uses lower-level features through well-defined layer-specific interfaces. 
• Services are tied to infrastructure resources: owners of the service features and functionality are also the owners of the physical resources.

However, cloud services tend to be architected differently, which enables a simpler paradigm for coordination between orchestrators as I will show later.

Modern cloud service architectures typically have the following features:

• Built from micro-services: Rather than providing monolithic service functionality, many services are built as micro-services that provide only a small number of primitive features. Larger services are then constructed by composing these micro-services into more sophisticated service behaviors.
• Recursion rather than layering is used as an organizing construct. Rather than accessing features through layer-specific interfaces, functionality is accessed using generic service interfaces that are the same at all layers of the stack. This enables recursion where the same composition process can be repeated at all layers: micro-services are used as components in more feature-rich services that then in turn can be used as components themselves for building even more sophisticated services.
• Features are decoupled from resources. In a virtualized world, the owners of the features and functionality are not necessarily the same as the owners of the physical infrastructure. That means that functionality can be deployed anywhere.

What's important here is that these architectural trends affect not only the services themselves but also the service orchestration process. They allow service orchestrators to use recursive decomposition as a new paradigm for orchestrating services. Using recursive decomposition, the orchestration process starts as before by decomposing top-level services into their lower level components. However, because of recursion, each of these components is a service in its own right that can in turn be decomposed into more fine-grain components. This decomposition process repeats itself until it results in components that can be realized on top of the resources that are available to the orchestrator.

The recursive decomposition paradigm has and important implication on the interactions between orchestrators: since components are also services, an orchestrator can decide at each step in the decomposition process whether to manage a component itself, or whether to hand off responsibility for that component to a different orchestrator in a different domain. When responsibility for a component is handed off to a different orchestrator, that orchestrator will in turn use recursive decomposition to deploy that component on its own resources.

In this scenario, the interaction model between cooperating orchestrators is one of delegation rather than federation. We define delegation as the entrustment by one entity of work and/or responsibility to another entity, and the creation of associated accountability for performance. This relationship is similar to a general contractor/sub-contractor relationship. Each service has one master orchestrator that owns the customer relationship and that acts as the general contractor. The master orchestrator may use other orchestrators in a sub-contractor role, but when many subcontractors are involved, it is the responsibility of the master orchestrator to coordinate between them. No direct coordination between the sub-contractors should be necessary.

The main benefit of the delegation paradigm is that delegation relationships are hierarchical rather than peer-to-peer at all levels. This means that the only interfaces required to communicate between orchestrators are their regular consumer/provider interfaces and there is no need for special peer-to-peer federation interfaces and/or protocols.

More importantly, delegation also means that there is no longer a need to set up pairwise business arrangements before service providers can start cooperating. Without any special arrangements in place, one service provider can delegate to another service provider using that service provider’s standard consumer/provider relationship.

The only peer-to-peer relationships that might still exist are at the infrastructure level, where resources from different providers need to be interconnected to enable end-to-end services. However, such connectivity does not require traditional federation relationships since it only serves to create reachability and does not immediately result in resource use. Infrastructure resources can only be used after they have been allocated in the context of services deployed on those resources, and such allocation is done in done in the context of a delegation relationship between the infrastructure provider and another service provider.

In summary, recursive decomposition significantly simplifies the required relationships between service providers, which can only accelerate the adoption of complex multi-domain services.