Getting to know Temporal

Поділитися
Вставка

КОМЕНТАРІ • 27

  • @JohnMcclaned
    @JohnMcclaned Рік тому +53

    shh, stop telling everyone about temporal, it's a competitive advantage.

  • @bartlettpsj
    @bartlettpsj 4 місяці тому +3

    Getting more interested in Temporal now I've got the teeshirt. Temporal seems more programmer first in that Workflows are defined in code. Many other Workflow (older?) products tend to use a UX or some form of configuration file (e.g. XML). Are there plans to have the ability to configure workflows through a UI, and then you just write the activities?

  • @wangyongt
    @wangyongt 10 місяців тому +3

    How to compare it with Azure Logic Apps? Which is much simpler and the author can fully focus on the business logic

    • @Temporalio
      @Temporalio  9 місяців тому +7

      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).

  • @RavikumarMooli
    @RavikumarMooli Рік тому +1

    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

    • @Temporalio
      @Temporalio  Рік тому +3

      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/

  • @rajat0610
    @rajat0610 Рік тому +7

    this is amazing!

  • @nikitos006
    @nikitos006 Рік тому +6

    amazing!

  • @maf_aka
    @maf_aka 11 місяців тому +4

    I guess I'm missing something, but doesn't this create a single point of failure?

    • @jwpraas
      @jwpraas 11 місяців тому

      Without temporal, there's multiple points of failure

    • @maf_aka
      @maf_aka 11 місяців тому +2

      @@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
      @maf_aka 11 місяців тому +2

      I guess my real question is: what's the home-run feature of a centralized control for distributed systems like temporal?

    • @loren-sr
      @loren-sr 10 місяців тому +3

      ​@@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.

    • @jesserigon
      @jesserigon 8 місяців тому

      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.

  • @nonefvnfvnjnjnjevjenjvonej3384

    Don't retriable jobs aka sidekiq in rails also solve this problem? Can you kindly explain what Temporal provides in addition to that?

    • @maximfateev2369
      @maximfateev2369 Рік тому +6

      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".

    • @Andreas-gh6is
      @Andreas-gh6is Рік тому

      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.

  • @_sudipidus_
    @_sudipidus_ Місяць тому

    Andy Dufrense has come a long way after escaping shawshwank :P

  • @ahimhaim9209
    @ahimhaim9209 Рік тому

    *jBPM flashbacks :D*

  • @dragondeviento93
    @dragondeviento93 2 місяці тому

    LOL 3.5 year "A lifetime, a life time" LOL this is just so F funny

  • @walletien
    @walletien 4 місяці тому

    amazing!