“DANCING OR PLAYING – THAT IS THE QUESTION?”
Welcome to part 3 of our blog series on Microservices – a young approach to IT architecture that replaces monolithic system dinosaurs with highly agile swarms of compact, autonomous services. The trick is to organize numerous individual services to create a meaningful, efficient, agile system.
No car can drive on one single wheel, and no business process consists of one single service: Microservices such as Billing, Payment and Shipping need to collaborate to create a value adding business process.
Such collaborations are either orchestrated or choreographed. What you have to know when making you choice is:
Choreographed Microservices will behave like dancing couples in a ballroom that, while keeping their individual routines, will react to each other, dodge each other, and all that without any centralized control. This is asynchronous, event-based communication:
Instead of directly contacting other services, choreographed Microservices will write relevant events into a message bus, e.g. Apache Kafka, which other services monitor for relevant events. For instance, if the Customer Service publishes the event ‘Customer Created’ while creating a new customer profile, the Loyalty Service will respond with the corresponding next process steps.
This adds up to a step-by-step event chain that covers the entire business process. Central control systems become obsolete and the coupling between individual services is as loose as ever possible – an ideal state in Microservice architecture.
So why not choreograph every Microservice architecture? Because achieving ideal states carries costs. Users of choreographed services pay with increased complexity due to asynchronous communication, with a total abstraction that either reflects business processes only implicitly as events or hides them completely in lines of code, and with challenges in process monitoring, because choreographed systems provide no information on running processes, error occurrence, etc. Monitoring has to be installed separately as costly custom solutions.
Furthermore, choreographed systems will only partially fulfill the promise of fully autonomous individual services: the message input and output of the services will create an indirect coupling that requires adapting multiple services whenever implementing new requirements – in blatant contradiction to the Microservice philosophy.
Solving these shortcomings would require an event command transformation outside the responsibility of the services involved. A separate service would be needed for this task, for example by a BPM engine, which in turn would mark a first step towards central orchestration.
In view of these complications, it becomes clear why orchestrated Microservice systems are now widely popular: in contrast to choreography, they are equipped with a central control unit, which directs the overall flow like a conductor directs orchestra musicians. REST is a frequently used communication line between control units and services. Lightweight BPM engines such as Camunda, Zeebe or Conductor are suitable central orchestrators.
Such orchestrated solutions initially had to struggle with prejudice. Now they are about to overtake the originally highly popular choreography solutions. Learn why – in Part 4 of our blog series.