Service Orchestration
The flowchart is arguably the oldest modeling tool in software engineering. Its sim‐ plicity, with a handful of symbols, makes it adaptable enough to illustrate the logic of the first program you wrote at school or a complex workflow at your organization. A workflow captures the different steps or processes involved in fulfilling a business functionality, often mixed with business processes. For example, onboarding a new employee in your organization is a process, and the workflow involves several steps, both manual and automated. The advantage of capturing a business process as a sequence of input, output, actions, tasks, decisions, etc., is that you can automate the entire process to improve efficiency.
Whether you use a workflow system or a business process management tool, there is an engine that has the knowledge of the overall workflow required to handle the input and output of each step, send commands to perform tasks, branch off to subflows based on certain decisions, collate results from multiple branches, and so on. This engine acts like a controller or conductor, instructing the different parts of the process to perform. Hence, this pattern is commonly referred to as orchestration of services, as in an orchestra where the conductor is the orchestrator.
AWS Step Functions is a serverless AWS service that offers orchestration capabilities.
What Do You Orchestrate?
Let’s look at a simple example to illustrate business process orchestration. Imagine you are placing an order at a local take-out restaurant. You’re at the point where you need to decide whether to collect the food you’ve ordered or get it delivered. Figure 5-34 shows a simple flowchart depicting the actions involved in each process behind the scenes.
Figure 5-34. A flowchart depicting the flow of food delivery and collection activities
On the company’s side, if you implement this logic with Lambda functions, you will have a function to receive the customer’s choice and some if-else logic that branches off into collection and delivery paths and invokes other Lambda functions or external APIs. You may implement the main function as a monolith and create single-purpose functions for other tasks. Nevertheless, you must somehow chain these functions together to make the end-to-end flow work. Figure 5-35 shows the main Lambda function that acts as the controller of the logic.
Figure 5-35. An unsustainable and unrecommended way of chaining Lambda functions to perform business logic
Creating hard dependencies between Lambda functions or making synchronous invocations between Lambda functions is not a best practice. In addition, as you learned earlier with the functionless integration pattern, there will be situations where you do not use Lambda functions to perform parts of your business logic. You need a way of capturing the business process as a whole and having a controller to coordinate with services that perform the different parts of the overall logic. Service orchestration is the architectural pattern that helps you achieve this.
In a distributed event-driven microservices architecture, you’ll find three types of orchestration:
- In-service orchestration
- Cross-service orchestration
- Distributed orchestration
We’ll dive into each of these in the sections that follow.