Choreography vs. Orchestration for football fans

Recently, I worked on a micro-services project which is cool thing but also challenging. Micro-services can solve many problems but also brings a panel of challenges.

Today we'll focus on micro-services communication challenge and for that we'll need a little bit knowledge of football and Ultras world specially.

Spoiler : I'm a fan of Wydad Athletic Club, a Moroccan sports club.

µServices communication challenge

If we build a micro-services architecture, in general we have at some point a communication between different/all services.

Those needs to communicate come with difficulties while the number of (business) services increase. We can imagine a simple business use case today can be chaotic in the future as business needs grows and changes.

In micro-services world and specifically communicating between different services, 2 main ways comes to mind : Choreography & Orchestration.

On Internet, you can find most of the articles explaining this topic with the comparison between Dancers (Choreography) and Orchestra (Orchestration) which is good explanation, but let's try a different way.

CHOREOGRAPHY :

Is Tifo sounds familiar to you ?

If not and in nutshell way, Tifo is a visual choreography performed by ultra using different materials. This performance needs a lot of preparation by many persons but also a lot of collaboration and communication.

In a Tifo choreography, supporters are synchronized, move and accomplish their missions with no central task decider. Everything is prepared and repeated previously (days, months ago) .

Similar in µService world, perform a business process needs the involve of different services to be completed. The code is written, services deployed and ready to execute.

With choreography, every service is talking to another service with no mediator in the middle. Each service knows about the other. The business logic is distributed.

The workflow initiator service triggers the (business) flow by informing each service participant which will performs its tasks and informs other services.

Pros :

• Distributed business logic with no centralized point
• Decision logic managed by the service (= team)
• Works well with agile delivery approach

Cons :

• Peer to peer event chains (excellent description here by Bernd Rücker)
• One service needs to subscribe to many events (is it healthy in a large scale architecture ? )
• Complexity to change the flow of business processes (e.g It'll be complex to change the shopping flow : Delivery before payment)
• Error handling can be a nightmare as each service (team) have the responsibility to understand how other services work and prevent cascading failure.

ORCHESTRATION :

Did you see this man in the middle surrounded by a lot of supporters ? This is the Capo in football and ultras jargon.

Capo means "head" in Italian. He is the representative leader of a group of ultras supporters. As you can see in the image, his back to the game and his face to supporters to lead them in terms of chants and movements (Headphones and low volume highly recommended).

Capo is the guarantor of the show

Yes, you're right if you guessed that Capo is Orchestrator in Orchestrated µService architecture.

Orchestration is driven by a central system (the Orchestrator in general) which is the responsible to determine what to do, when and by who in order to guide and control a business workflow/process, which is very similar to the Capo who controls the movements and chants of supporters.

Supporters = Workers in orchestrated architecture and workers are – generally– your business services (e.g shipment, delivery, payment).

Each worker performs its tasks and informs the Orchestrator by returning the result. The Orchestrator takes decisions for the next steps.

Pros :

• Flexibility : Easy to change and evolve the business workflows and processes
• DRY : The workflow logic is on the same place
• Clear monitoring of your processes progress

Cons :

• The workflow engine becomes a central piece of the architecture and could be SPoF
• As its very important component, the orchestrator could become more proprietary than the business itself in terms of operations specially with a decentralized approach.

Conclusion

Both of architectures are valid but the choice depends on the complexity of your µService world.

For a small/medium systems with moderated complexity, I would say go for Choreography but if the number of events is large or can increase in the near future, it'll become more and more complex to handle the code and logic in individual services. Whereas Orchestration can be more elegant in handling multiple events with less confusion.

For sure you can mix the both architectures – as Ultras do to support their clubs while spending a lot of time, effort and engagement to have such impressive results – but don't push your luck.

Resources

Header photo by sergio souza on Unsplash