Temporal is focused on making code run reliably. You can write arbitrary logic in code, and Temporal makes it run durably, and orchestrates each step. DAG-based Workflow systems like Azure Logic and Step Functions are limited in their flexibility, and beyond simple cases, are harder to develop (defining if/then/else or loops in a UI or in JSON, devs can't use their normal testing and debugging tools, etc).
I had a usecase in which checking for sufficient information to perform next activity but if it fails it needs to go parent workflow how should i do it using temporal
Do you mean you need the activity failure to propagate to the parent workflow? If it's a non-retryable failure, the activity will fail, and it's not caught by the workflow, it will fail the workflow, and then a failure will be thrown from where the parent is waiting on the result of the child (e.g. from `await childWorkflowHandle.result()` in TypeScript). Apologies if I'm misunderstanding. Also, you can expect faster responses to questions on our forum: community.temporal.io/
Temporal doesn't retry the whole "job". It moves it with all the state (including local variables and stack) to another machine. So from the programmer's point of view, the job keeps running as if nothing happened. It also means that no explicit DB updates are needed to keep the state of the "job".
Only if it's basically one single job. The problem that Temporal solves is multiple steps that each can take some time or fail or need to be cleaned up.
@@jwpraas no it won't? if the process fails you catch the exception/ return the error early so it won't propagate, and call rollback functions if it's supposed to be part of a transactional flow... it's the same with or without temporal.
@@maf_aka Home run features are reliability and developer velocity. The ways you get reliability without Temporal is by persisting things to various queues, timers, and databases, and writing code to save and update and progress the data / state of a business process. The more code gets written, the more bugs get written. The more sources of data, the more inconsistent data and race conditions you get. Temporal is a single source of truth, can transactionally update the queues, timers, and state, since they're all in the same DB, and takes care of most of the reliability code, so you don't have to write it, which means you can develop faster. For instance, you can implement a SAGA with choreography, publishing and subscribing to an event bus, or orchestration, writing logic in JSON for AWS step functions, or you can write a function in Temporal that's guaranteed to execute, and implement a SAGA with a try/catch statement. The single function is much faster to write and get correct (for example, in the choreography case, you need to use a transfer queue every time you publish to the bus in order to guarantee consistency). To your SPOF concern-Temporal is a good point of failure to have. Each part of the system is horizontally scalable and fault tolerant, and if any piece goes down, it will come back up in a consistent state. We have a Global Namespace feature with an RTO of 20min (fails over to a backup region on loss of primary, time to be reduced in future), RPO of ~0, guarantees 99.99% availability, and in most cases will be much better than that.
I never understood this term. Nothing is a single point of failure. Just because a car can turn with just a steering wheel doesn't mean it's literally just a steering wheel. There are hundreds of failure points underneath that in a cars turning capabilities. It's turtles all the way down. Not advocating temporal, just saying the expression never made sense to me.
shh, stop telling everyone about temporal, it's a competitive advantage.
haha XD
so true!
this is amazing!
amazing!
How to compare it with Azure Logic Apps? Which is much simpler and the author can fully focus on the business logic
Temporal is focused on making code run reliably. You can write arbitrary logic in code, and Temporal makes it run durably, and orchestrates each step. DAG-based Workflow systems like Azure Logic and Step Functions are limited in their flexibility, and beyond simple cases, are harder to develop (defining if/then/else or loops in a UI or in JSON, devs can't use their normal testing and debugging tools, etc).
I had a usecase in which checking for sufficient information to perform next activity but if it fails it needs to go parent workflow how should i do it using temporal
Do you mean you need the activity failure to propagate to the parent workflow? If it's a non-retryable failure, the activity will fail, and it's not caught by the workflow, it will fail the workflow, and then a failure will be thrown from where the parent is waiting on the result of the child (e.g. from `await childWorkflowHandle.result()` in TypeScript).
Apologies if I'm misunderstanding. Also, you can expect faster responses to questions on our forum: community.temporal.io/
Don't retriable jobs aka sidekiq in rails also solve this problem? Can you kindly explain what Temporal provides in addition to that?
Temporal doesn't retry the whole "job". It moves it with all the state (including local variables and stack) to another machine. So from the programmer's point of view, the job keeps running as if nothing happened. It also means that no explicit DB updates are needed to keep the state of the "job".
Only if it's basically one single job. The problem that Temporal solves is multiple steps that each can take some time or fail or need to be cleaned up.
I guess I'm missing something, but doesn't this create a single point of failure?
Without temporal, there's multiple points of failure
@@jwpraas no it won't? if the process fails you catch the exception/ return the error early so it won't propagate, and call rollback functions if it's supposed to be part of a transactional flow... it's the same with or without temporal.
I guess my real question is: what's the home-run feature of a centralized control for distributed systems like temporal?
@@maf_aka Home run features are reliability and developer velocity. The ways you get reliability without Temporal is by persisting things to various queues, timers, and databases, and writing code to save and update and progress the data / state of a business process. The more code gets written, the more bugs get written. The more sources of data, the more inconsistent data and race conditions you get. Temporal is a single source of truth, can transactionally update the queues, timers, and state, since they're all in the same DB, and takes care of most of the reliability code, so you don't have to write it, which means you can develop faster. For instance, you can implement a SAGA with choreography, publishing and subscribing to an event bus, or orchestration, writing logic in JSON for AWS step functions, or you can write a function in Temporal that's guaranteed to execute, and implement a SAGA with a try/catch statement. The single function is much faster to write and get correct (for example, in the choreography case, you need to use a transfer queue every time you publish to the bus in order to guarantee consistency).
To your SPOF concern-Temporal is a good point of failure to have. Each part of the system is horizontally scalable and fault tolerant, and if any piece goes down, it will come back up in a consistent state. We have a Global Namespace feature with an RTO of 20min (fails over to a backup region on loss of primary, time to be reduced in future), RPO of ~0, guarantees 99.99% availability, and in most cases will be much better than that.
I never understood this term. Nothing is a single point of failure. Just because a car can turn with just a steering wheel doesn't mean it's literally just a steering wheel. There are hundreds of failure points underneath that in a cars turning capabilities. It's turtles all the way down. Not advocating temporal, just saying the expression never made sense to me.
*jBPM flashbacks :D*
amazing!