First, let's start by describing the differences between Orchestration and Choreography:
Orchestration: An orchestrator controls the interactions between services. This orchestrator dictates the control flow of the business logic and makes sure that everything is executed according to this workflow.
Choreography: Every service does its work independently. There are no hard dependencies between services, and they are loosely coupled only through shared events. Each one of the services is interested about certain events and they will only listen to the specific events assigned to them. For example, this would be a good scenario for event-driven architectures that use lambda functions. That is the reason why this approach is extremely popular for serverless projects that benefit from SNS, SQS, Kinesis, Eventbridge...
As we can see, the advantages of a choreography approach are:
- There is no single point of failure
- Each step of the workflow can be modified and scaled independently from the rest of the services However, it is important to note that it will be very difficult to monitor all of those services and implement timeouts between events.
In order to solve that problem, one of the main paradigms that comes to mind is the implementation of a state machine, which is also another serverless service. As always, depending on the context one approach is more suitable than the other. It would be a mistake to draw the conclusion that all serverless projects should be inclined towards using a choreography approach.
By using an orchestrator approach with Step functions and Event Bridge monitoring becomes trivial because of the built-in visualizations and audit histories included with Step functions. It also gets easier to implement timeouts between state transitions, and all the business logic is stored in one central unit, namely a state machine that is easy to maintain and manage.
Top comments (0)