Hi James, thanks, amazing video and explanation! You've clarified me a lot the differences between Orchestration and Choreography in such scenarios. I'm wondering if the need of predefining the channel to publish the response back (from the payment service in that example) is due to having multiple orchestrators. If there is only one, would it be necessary to predefine it, or would just sending the correlationId be enough? Thanks in advance!
I think you'd probably want one responseChannel per orchestrator. The consumer of the message would always need to know where to send a message back to. Just having a correlationId wouldn't help them know what to do with it :) You could even make the responseChannel something like AWS API Gateway with a direct integration into SQS. So the consumer is just making HTTP API calls, but you have the freedom to change the underlying channel implementation.
Hi @@serverlessjames ! thanks for the response, If I'm not missing any of the parts of the puzzle, (and sorry if I'm not doing que question properly) I'm asking explicitly about the need of the orchestrator to specify the response channel in the message pusblished in the first step. If you have just one orchestrator in that case, can't the payment service already have a predefined channel where to leave the response messages along with the CorrelationId without the need for the orchestrator to tell you so? Thanks in advance again!
@@xaberueoh, i understand your point now. Yes, it absolutely could be predefined. But then if hte producer needs to change it, you need to make changes in 2 services.
@@serverlessjames that's true, your recommendation makes the services more autonomous to changes. thanks for taking your time to reply and clarify it !!
Just to make sure I'm connecting the dots. Are these orchestrators sometimes referred to as "Sagas" (thinking MassTransit). And in native AWS land, you could do request response using SQS temporary queues?
Kind of :) You would use an orchestrator with a Saga. The big difference with a Saga is that you would have a compensating action when things didn't work, to rollback the changes. That gives me an idea for another video though, covering the Saga pattern :) Thanks for the comment Brendon. Yes, you could absoloutely use a temporary queue. I'd prefer to use a single queue wired up to a Lambda function or something, and then use the correlationId to provide the mapping back to the right orchestrator.
Thanks. I’ve been wrestling with the best way to approach some long running background process that have a series of async steps in a serverless pattern. Looking at patterns there seems to be vague similarities with state machines and aggregate roots / event sourcing. Yet another place where the lines get blurry for me. Perhaps another video/talk idea.
The events and commands are the methods to communicate in an event driven application. Instead using requests/response it uses pubsub approach/pattern. With that , if you need transactions like ACID transactions in databases, you would need to use SAGA pattern (Coreography or orchestration) or any other method (2 phase commit ) using previous patterns.
Very good explanation
Hi James, thanks, amazing video and explanation!
You've clarified me a lot the differences between Orchestration and Choreography in such scenarios.
I'm wondering if the need of predefining the channel to publish the response back (from the payment service in that example) is due to having multiple orchestrators. If there is only one, would it be necessary to predefine it, or would just sending the correlationId be enough?
Thanks in advance!
I think you'd probably want one responseChannel per orchestrator. The consumer of the message would always need to know where to send a message back to. Just having a correlationId wouldn't help them know what to do with it :) You could even make the responseChannel something like AWS API Gateway with a direct integration into SQS. So the consumer is just making HTTP API calls, but you have the freedom to change the underlying channel implementation.
Hi @@serverlessjames ! thanks for the response, If I'm not missing any of the parts of the puzzle, (and sorry if I'm not doing que question properly) I'm asking explicitly about the need of the orchestrator to specify the response channel in the message pusblished in the first step. If you have just one orchestrator in that case, can't the payment service already have a predefined channel where to leave the response messages along with the CorrelationId without the need for the orchestrator to tell you so?
Thanks in advance again!
@@xaberueoh, i understand your point now. Yes, it absolutely could be predefined. But then if hte producer needs to change it, you need to make changes in 2 services.
@@serverlessjames that's true, your recommendation makes the services more autonomous to changes. thanks for taking your time to reply and clarify it !!
Just to make sure I'm connecting the dots. Are these orchestrators sometimes referred to as "Sagas" (thinking MassTransit).
And in native AWS land, you could do request response using SQS temporary queues?
Kind of :) You would use an orchestrator with a Saga. The big difference with a Saga is that you would have a compensating action when things didn't work, to rollback the changes. That gives me an idea for another video though, covering the Saga pattern :) Thanks for the comment Brendon.
Yes, you could absoloutely use a temporary queue. I'd prefer to use a single queue wired up to a Lambda function or something, and then use the correlationId to provide the mapping back to the right orchestrator.
Thanks. I’ve been wrestling with the best way to approach some long running background process that have a series of async steps in a serverless pattern. Looking at patterns there seems to be vague similarities with state machines and aggregate roots / event sourcing. Yet another place where the lines get blurry for me. Perhaps another video/talk idea.
The events and commands are the methods to communicate in an event driven application. Instead using requests/response it uses pubsub approach/pattern. With that , if you need transactions like ACID transactions in databases, you would need to use SAGA pattern (Coreography or orchestration) or any other method (2 phase commit ) using previous patterns.