There's been more and more buzz lately around the subject of microservices architectures for business applications and whether to use choreography or orchestration to manage them. In this article, I'll cover a bit about microservices architecture as it relates to enterprise application development and a lot more about what orchestration means and the different approaches and technologies related to microservices orchestration.
The advantage that microservices offer is great flexibility and deployability using cloud-based components.
Microservices are autonomous deployable entities that can interact with each other directly as needed. Let's look at, as an example, the case of customer interactions with MobileBank, a hypothetical mobile banking app offering a promotional gift of credit in exchange for using the app to purchase a product. MobileBank is also on the alert for opportunities to make special offers to encourage customer loyalty.
From the customer's point of view, there are a number of key steps, from purchasing the product with the mobile app to receiving credit for a future purchase to using that credit on another purchase.
From the application point of view, each of these transactions can be handled using microservice choreography. When it works, it works great! But what happens when there is an error? When there are a lot of service calls and no overall process, it's difficult to see where the error could be.
What if it's in the purchase interaction? When the online retail system is temporarily unavailable? When you do a network call and it fails, you don't know why. Did the call fail to reach the service provider? Did the service provider have a failure? Did your system fail to receive the callback? If it is the third case, the customer's account has been charged, so if they try to purchase the item again, your service may charge the account again. Now, a clean-up may be needed to cancel the first transaction and avoid an unhappy customer.
Increasing complexity shows the limits of microservices choreography
Microservices pioneers like Netflix are learning the limitation of choreography. On the company's technology blog, it noted that "with peer to peer task choreography, we found it was harder to scale with growing business needs and complexities."
Its experience is worth looking at. Some of the issues it was encountering with the choreography approach included "tight coupling and assumptions around input/output, SLAs, etc. within individual services, making it harder to adapt to changing needs" and no overall tracking, making it difficult to "systematically answer 'How much are we done with process X?'"
Netflix ultimately decided that with complexity increasing as it added services, the use of an orchestration engine to manage the overall process was a more flexible and, therefore, more attractive approach than choreography. So it built an open-source platform called Conductor to provide the overall logic to orchestrate its microservices-based process flows.
The different flavors of microservices orchestration
Orchestration used to have a bad reputation in the microservices ecosystem, as it was considered an antipattern. Each microservice should be independent of other microservices, so there was no room for a centralized orchestration approach.
There's no rule that says orchestration needs to be centralized. Orchestration can be used instead to extract the business logic of each individual microservice or even to provide visibility into a sequence of microservices calls.
In addition to Conductor, I've seen more and more new orchestration frameworks such as Cadence and Apache Airflow to help developers code the orchestration flow of microservices.
Other workflow frameworks such as Camunda, Flowable and Bonita offer an alternative approach to microservices orchestration in which the process flow can also be graphically defined using the Business Process Model and Notation (BPMN) standard. That way, it becomes easier to understand the whole logic and to collaborate during the orchestration flow definition.
Some of the visible advantages of this latter approach are:
- Errors can be handled automatically exactly where they can happen using exception paths, timers and other BPMN elements. If human intervention might be needed, that can be included in the logic as well.
- BPMN allows the definition of rules for routing data and data handling — as in the logic of how tasks are assigned to the right services, to the right people and so on.
- Data on cases and process execution is compiled for reporting, monitoring and analytics.
Other orchestration use cases include coordination of systems, humans and robots
Orchestration frameworks offer even more than just microservices orchestration. They allow orchestration — and automation — of any service: operations managed through APIs, integrations with legacy and proprietary specialty systems, integrations with "monoliths" such as SAP and other ERP platform operations, IoT integrations and the like. Our MobileBank can use its parent company's legacy CRS, SAP and approval processes right alongside its purchasing and crediting microservices.
Then there are those tasks "assigned to people" I mentioned above. BPMN modeling is expressly designed for the orchestration of human and automated IS tasks, creating a mix of what people need to act on in a process such as for approvals (let's run a special waiver for a certain target sector — that needs a supervisor), escalations for issues (needs a division manager?), delegations for absences (when it's August in France) and the like.
Now, there is a new set of actors: software robots. Repetitive, mechanical tasks that humans perform are ideal candidates for delegation to those robots. In the example case of MobileBank, robot assistants can collect, retrieve and collate customer information that might be useful to make an instant special offer.
Orchestration can handle a much broader mix than just microservices. In future articles, I will illustrate with examples those other orchestration use cases involving services, humans and robots.
