Thanks for this great explanation in detail! I think that the orchestration-based communication might possibly make developers stuck in high traffic. Since the choreography-based allows us to make point-to-point communication between the services, we can easily make this communication asynchronous with message queues so that the services can be loosely coupled. Each of them has a single job and if one of them is down, in case of any failure, the rest of them will not be affected (it somewhat affects the transaction but not the whole system). On the other hand, once we apply the orchestration-based communication, there will be a centralized manager that orchestrates the business flow sequentially. In that scenario, what I see is that we somehow need to call the procedures (e.g, REST call) from related services and wait for their responses to execute the next iterations. It might seem like a kind of synchronous centralized communication. Under the high traffic, all related services of a given transaction receive high requests. What do you think about this concern? How do we design our orchestration?
I think this problem will be there in choreography too, if there is a need of synchronous communication we can't replace it with message queues. I think only thing we can focus is to keep service highly available and take all the precautions, kindly let me know what do you think about this, Thanks
Do you have any real example about, choreographer and orchestration. When we need orchestration?
I try to use, my scenary with services REST API and Web Service SOAP-XML.
I don't know, if my scenary is a Orchestration or Middleware, any idea?
as the number of micro-services keeps growing, the orchestrator is going to be a big single service, its maintainability is also a problem?
Orchestrator Scalability vs Choreography??
nicely explained!
Thanks for this great explanation in detail! I think that the orchestration-based communication might possibly make developers stuck in high traffic. Since the choreography-based allows us to make point-to-point communication between the services, we can easily make this communication asynchronous with message queues so that the services can be loosely coupled. Each of them has a single job and if one of them is down, in case of any failure, the rest of them will not be affected (it somewhat affects the transaction but not the whole system). On the other hand, once we apply the orchestration-based communication, there will be a centralized manager that orchestrates the business flow sequentially. In that scenario, what I see is that we somehow need to call the procedures (e.g, REST call) from related services and wait for their responses to execute the next iterations. It might seem like a kind of synchronous centralized communication. Under the high traffic, all related services of a given transaction receive high requests. What do you think about this concern? How do we design our orchestration?
I think this problem will be there in choreography too, if there is a need of synchronous communication we can't replace it with message queues. I think only thing we can focus is to keep service highly available and take all the precautions, kindly let me know what do you think about this, Thanks