It does. It can be easy to conflate service orchestration with turn-up, testing, configuration, control, management, and even the broader category of network automation itself. It’s fairer to describe service orchestration as a subset of all of the above. However, when the DevOps and cloud connector teams start talking about service choreography, it’s vitally important to define what orchestration means to your organization and precisely what choreography will accomplish that orchestration cannot. That starts with understanding what orchestration and choreography are and when it’s best to use them.
Service Orchestration
A network orchestrator is an automation platform that combines and invokes processes and/or services using fixed logic to coordinate interactions that produce a specific outcome. It can be as simple as automating a single manual task into a workflow and as complex as creating a composite service with multiple service invocations. An orchestrated service can be an object in its own right, with the relationship between the cooperating service(s) understood in the broader context of the services delivered by the orchestration platform.
Although orchestration is often hierarchical, it doesn’t have to be. It is well suited to providing automation in a single technology domain.
A centralized orchestrator:
- Centrally coordinates component processes or services
- Does not require component services to be aware of associated processes
- Includes error handling and fault management that can invoke an alternative method if a process fails
Service Choreography
Service choreography automates the exchange of asynchronous information, or messages, between multiple services. Choreographed services use distributed control logic, are usually event-based, and are well-suited to cross-domain process automation. Choreographed services “understand” the timing of information exchanges, act when an information exchange recognizes target conditions, and follow instructions that accommodate those conditions.
Choreography specifies how the interactions of two or more processes (which may not have visibility or control over each other) work together to deliver a singular, unique service. Because choreography facilitates collaboration across multidomain orchestration and control systems, it’s a good fit for multivendor network automation. Network automation that leverages containerized microservices and applications are great candidates for choreography that spans multiple domains.
Distributed choreography:
- Eliminates a single point of failure from a monolithic orchestrator using loosely coupled services that can be modified without impacting the end- to-end service
- Does not suffer from increased performance overhead as the service library grows and gains complexity
- Supports Saga and CRUD (create, read, update, delete) patterns that describe, coordinate, and make changes to distributed, intelligent processes
Combining Service Orchestration and Service Choreography
While clearly different, orchestration and choreography can be combined to create expanded network automation capabilities. For example, use orchestration for “core” synchronous workflows that use the same logic over and over, and use choreography to deliver asynchronous messages back to source services (or microapplications) that execute in target network conditions.
Design patterns like Saga and CRUD support this kind of advanced network automation. A saga is a logic narrative that defines a sequence of operations that are triggered when certain conditions are met. The CRUD pattern performs create, read, update, or delete transactions and then publishes a message prompting the next step in the process. When a network outage disrupts an end-to-end service that spans multiple layers, vendor domains, and technologies, a recovery saga can invoke orchestration, control, and management to perform highly distributed restoration processes.
Network software architecture that includes containers and microservices
Sagas live in network orchestrator or exist across a series of microservices and microapplications that are connected via message broker. In the previous example, both can invoke the recovery saga, restoring service components automatically and gracefully, shortening the mean time to repair (MTTR) without requiring human intervention.
There are other ways to use orchestration and choreography pattern coordination. The orchestrator might tell domain subscribers which transactions to execute and when, while choreographed services trigger local transactions for cross-domain subscribers. The orchestrator knows and executes its own behaviors, while choreography waits for certain behaviors to occur before acting.
In a nutshell, orchestration is the answer when centralized logic can be used to automate a process. When a process needs distributed updates to its components in order to do its job correctly, choreography is the answer.
Proprietary Systems Make Network Automation More Challenging
It can be difficult to use proprietary network orchestration and management systems to automate multivendor networks that are connected to multiple clouds. Proprietary tools lack the open control, integration, and interoperability that is needed to optimize end-to-end service delivery. What’s more, it doesn’t matter how fast or how far a device can move network traffic if that same traffic gets bogged down with the system overhead that 5G service delivery is capable of creating. Quality of Service (QoS) and Quality of Experience (QOE) difficulties accelerate when cloud services are added at the network edge.
For more information about the Fujitsu open network control and orchestration solutions, please see the Virtuora Service Orchestrator Solution Brief, or come see us at The Big 5G Event in Denver, Colorado Sep 1-2, 2021.