mfateev

Do you realize that Temporal is fully open source under the MIT License, while the competitor is under BSL?

I certainly don't think I'm superior to them in any way and have great respect for the very capable team they are. We know each other personally. I even presented at the Flink conference while at Uber.

My message is that I'd prefer a more technical discussion of the merits of our products rather than simplified marketing attacks.

Disclaimer: I'm a co-founder of Temporal.

Temporal has 3 types of activities:

* local: executed in the same process as the orchestrator code. Many local activities can be executed locally before their results are sent to a backend server in a single RPC call.

* task queue based: executed by a pool of worker processes that poll from the queue. This is the most flexible model as it supports flow control, priorities, fair queueing out of the box.

* eager dispatch: task queue based but executed locally if possible as a performance optimization.

Temporal also supports stand alone activities that are invoked without a workflow and dispatched through a task queue.

Restate only supports local activities (using Temporal terminology).

I wouldn't call it a "more flexible programming model".

Restate made several decisions I consider questionable for the system's availability and stability, like pushing work to handlers instead of dispatching it through a queue. Any design decision has tradeoffs. It would be nice if you mentioned these trade-offs in your posts instead of making claims that sound like pure marketing.

Fun fact: The first-ever Durable Execution POC at AWS Simple Workflow used snapshots. The workflow was implemented as a fully asynchronous Java application, and a snapshot was a dump of the whole object graph using reflection. Performance was abysmal because a snapshot had to be generated after every state transition.

So we switched to replay. The biggest benefit of replay is that it lets you implement Durable Execution in any language as a library without a complex runtime. It also supports code changes while workflows are in flight (Temporal calls this patching). Making snapshots of arbitrary code state backward-compatible with code changes isn't practical.

I personally think that, in the long term, Durable Execution will use a runtime that supports both snapshotting and determinism. That way, snapshots can be taken infrequently, and replay can bring workflow code to the latest state. Similarly to a database recovering from a WAL. WASM is the most promising technology to achieve this.

That sounds like an excellent use for narrow boring company tunnels.

I don't believe in visual programming ever replacing code for general programming. However, many examples exist when visual programs work for narrow domain-specific applications. This works because such applications allow exposing only high-level domain-specific abstractions. This reduces complexity enough to be a good fit for visual representation.

Do you know about the Temporal startup program? It gives enough credits to offset support fees for 2 years. https://temporal.io/startup

Every step of the workflow is durably recorded. So you have the full information about the exact state of each workflow. To troubleshoot, you can even download the event history and replay workflow in a debugger as many times as needed.

The ease of troubleshooting is one of the frequently cited benefits of the approach.

Check the UI screenshot at https://www.temporal.io/how-it-works.

temporal.io just released .NET SDK. The observability and scalability of the platform is really good.

Disclaimer: I'm one of the founders of the project.

Check out temporal.io. It has support for schedules as well.

Check out temporal.io that fully abstract this. Disclaimer, I'm one of the founders.

State machines are useful when the same input/event requires different handling based on the current state. There are not that many applications when this is true. Most of the time only two handlers in each state are needed, success and failure, which are much better modeled through a normal code than an explicit state machine.

At the framework level they might be pretty useful, but they rarely appear at the first version, but as a result of refactoring.

Yes, Temporal workflows are as dynamic as needed.

The other useful pattern is always running workflows that can be used to model lifecycle of various entities. For example you can have an always running workflow per customer which would manage its service subscription and other customer related features.

The main difference is that workflows are written as code in a general purpose programming language. Java, Go, Javascript/Typescript and PHP are already supported. Python and .NET are under development. AWS Step Functions are using JSON to specify workflow logic. JSON is OK for very simple scenarios, but is not adequate for the majority real business use cases. The fun fact is that Step Functions are a thin layer on top of AWS SWF which is based on the same idea as Temporal.

Here is a more detailed answer from Temporal forum: https://community.temporal.io/t/why-use-temporal-over-a-comb...

Look at the temporal.io. It is essentially a BPM system that uses Go (as well as Java/PHP/Typescript) to specify business process. And a queue + DB is never simpler for such scenarios.

Disclaimer: I'm one of the founders of the project.

I think we are in agreement here. Temporal does exactly what you described. It uses queues to transporting tasks to processes. But it completely hides them from the business process code.

The issue is that 99.9% of developers use queues directly in their business applications.

I think queues are the wrong abstraction to model business processes. That's why a trivial issue like a non recoverable failure during processing a message becomes such a headache. The same goes for ordering. An orchestrator like temporal.io allows modeling your business use case using higher level abstractions that hide all this low level complexity.

Disclaimer: I'm the tech lead of the temporal.io open source project and the CEO of the affiliated company.

temporal.io provides much higher level abstraction for building asynchronous microservices. It allows one to model async invocations as synchronous blocking calls of any duration (months for example). And the state updates and queueing are transactional out of the box.

Here is an example using Typescript SDK:

   async function main(userId, intervals){ 
     // Send reminder emails, e.g. after 1, 7, and 30 days
   
     for (const interval of intervals) {
       await sleep(interval * DAYS);
       // can take hours if the downstream service is down
       await activities.sendEmail(interval, userId); 
     } 
     // Easily cancelled when user unsubscribes
   } 

Disclaimer: I'm one of the creators of the project.

A lot of startups these days support early exercise or extend the post termination exercise period from 90 days to much longer period like 10 years. So there is no need to stay with the company for 5-10 years after your options vested. The 4 year vesting schedule is standard.

Temporal takes much simpler approach to updating code while a program is running. For any code update, it keeps both old and the new version of the code. Then it uses the old code to replay already recorded events which allows to reconstruct the program state and takes the new code path when it is executed for the first time. Eventually the old code is removed once all the executions that used it are completed.

Google is mimicking perforce command line. The backend is 100% proprietary.

Microsoft is based on Git, but with a lot of engineering on top of it: https://devblogs.microsoft.com/bharry/scaling-git-and-some-b...

AWS DynamoDB is multi-AZ and is strongly consistent (at least for a single key update).

I believe you confused it with a Dynamo DB described in a paper Amazon published long ago. AWS DynamoDB has nothing to do with a eventually consistent design the paper describes. It was purely marketing gimmick to call the new AWS Service that.

> I also used to use Microsoft's Windows Workflow Foundation to do similar things. Essentially you're sketching a workflow process skeleton and then managing the state atomically by compartmentalizing it, so to speak.

temporal.io and Windows Workflow Foundation are completely different. WF uses code to generate an intermediate representation of the workflow AST. And that intermediate representation is executed. It is similar to the most existing workflow engines from Airflow to BMPN ones.

Temporal doesn't use any intermediate representation. It directly executes the code keeping all its state durable.

> I don't entirely agree with your comment about state management and argument passing in Petri nets.

When I say about the state I mean the overall state of the business project which is much more than a token in a certain dish. For example such state can include a list of line items to order with all associated attributes and counters of processed events.

> I'd argue that, the tool you describe could be modeled as a Petri net, but that perhaps you may not wish to have a user do it that way.

All software at the lowest level can be modeled as a state machine. And Petri net is one of the possible representation of FSN. I'm interested in simplifying the way the workflow logic is specified by an engineer. At this point I believe the temporal.io approach of giving your the full power of a high level programming language and taking care of durability and scalability is the best option.

I'm one of the original creators of temporal.io open source project.

Long time ago I worked with an internal Amazon workflow engine that was based on Petri nets. It worked, but I learned that for the majority of the business level workflows it was too low level. It was always a hassle to map a real use case to it.

The AWS Simple Workflow service was created as a replacement of that engine. It greatly elevated the lel of abstraction. The Azure Durable Functions, Uber Cadence, and our latest project temporal.io are all use this new way to represent workflows. The basic idea is to not implement the business logic using an intermediate representation. Instead rely on runtime to make any code state fully fault tolerant. Imagine that the full orchestrating program state (including threads, local variables and even blocking calls) is preserved across any process and other infrastructure failures. This allows to write production code like this:

      boolean trialPeriod = true;
      while (true) {
        Workflow.sleep(Duration.ofDays(30));
        activities.chargeMonthlyFee(customerId);
        if (trialPeriod) {
          activities.sendEndOfTrialEmail(customerId);
          trialPeriod = false;
        } else {
          activities.sendMonthlyChargeEmail(customerId);
        }
      }

As the state is fault tolerant the 30 day sleep is absolutely OK. And if any of this operations takes long time (for example because a downstream service is down for a day) the code doesn't need to change. I bet that any Petri nets based version of the above code would be much more complicated. One of the reasons that large part of the complexity of the business level workflows is not in sequencing of actions (which Petri nets solve), but in state management and argument passing (which Petri nets don't solve at all).

temporal.io

Great, show me a single product (besides AWS SWF and Azure durable Task Framework) that has the programming model of Temporal. For example, which product allows to write production code like this that survives any process failures:

  public void execute(String customerId) {
    activities.sendWelcomeEmail(customerId);
    try {
      boolean trialPeriod = true;
      while (true) {
        Workflow.sleep(Duration.ofDays(30));
        activities.chargeMonthlyFee(customerId);
        if (trialPeriod) {
          activities.sendEndOfTrialEmail(customerId);
          trialPeriod = false;
        } else {
          activities.sendMonthlyChargeEmail(customerId);
        }
      }
    } catch (CancellationException e) {
      activities.processSubscriptionCancellation(customerId);
      activities.sendSorryToSeeYouGoEmail(customerId);
    }
  }

temporal.io supports task heartbeating. An application specific data can be attached to each heartbeat. The data is accessible from outside to display the progress in the UI for example. The data from the last heartbeat is also available to a task when it is retried.

Did you click on temporal.io?

It is hard to describe as it is a new way to build distributed applications that doesn't have a commonly agreed name yet.

Because it is a hard problem to solve holistically.

It looks simple on the surface. So almost any company ends up creating an implementation similar to the one described in the article. Then it learns that it is much harder than looks, but it is usually too late. So they end up maintaining it for a long time with the original team long gone.

BTW I believe that temporal.io (I'm tech lead of the project) is so far the best open source solution to this problem.

It is not Go specific. It already supports both Go, Java and Ruby.

temporal.io our fork of Cadence will have PHP support very soon. Support for other languages is coming. Python and Typescript are the highest priority.

This is exactly the model Temporal provides. In languages that support await it is used. In languages like Java and Go normal blocking calls are used.