Temporal workflow vs Cadence workflow

Asked 11/4, 2020 at 13:18 Answered 19/9, 2020 at 0:46

Solved cadence-workflow temporal-workflow

How is temporal.io related to cadenceworkflow.io? What should be used if starting a new project depending on the cadence workflow service?

Isolative answered 11/4, 2020 at 13:18 Comment(0)

109

Disclaimer: I'm the original co-founder and tech lead of the Cadence project and currently co-founder/CTO of the Temporal Technologies.

temporal.io is the fork of the Cadence project by the original founders and tech leads of the Cadence project Maxim Fateev and Samar Abbas. The fork is fully open source under the same MIT (with some SDKs under Apache 2.0) license as Cadence. We started Temporal Technologies and received VC funding as we believe that the programming model that we pioneered through AWS Simple Workflow, Durable Task Framework and the Cadence project has potential which goes far beyond a single company. Having a commercial entity to drive the project forward is essential for the longevity of the project.

The temporal.io fork has all the features of Cadence as it constantly merges from it. It also implemented multiple new features.

Here are some of the technical differences between Cadence and Temporal as of initial release of the Temporal fork.

All thrift structures are replaced by protobuf ones

All public APIs of Cadence rely on Thrift. Thrift object are also stored in DB in serialized form.

Temporal converted all these structures to Protocol Buffers. This includes objects stored in the DB.

Communication protocol switched from TChannel to gRPC

Cadence relies on TChannel which was TCP based multiplexing protocol which was developed at Uber. TChannel has a lot of limitations like not supporting any security and having a very limited number of language bindings. It is essentially deprecated even at Uber.

Temporal uses gRPC for all interprocess communication.

TLS Support

Cadence doesn't support any communication security as it is a limitation of TChannel.

Temporal has support for mutual TLS and is going to support more advanced authentication and authorization features in the future.

Simplified configuration

Temporal has reworked the service configuration. Some of the most confusing parts of it are removed. For example, the need to configure membership seeds is eliminated. In temporal each host upon startup registers itself with the database and uses the list from the database as the seed list.

Release pipelines

Cadence doesn't test any publicly released artifacts including docker images as its internal release pipeline is ensuring the quality of the internally built artifacts only. It also doesn't perform any release testing for dependencies that are not used within Uber. For example, MySQL integration is not tested beyond rather incomplete unit tests. The same applies to the CLI and other components.

Temporal is making heavy investment into the release process. All the artifacts including a full supported matrix of dependencies are going to be subjected through a full release pipeline which is going to include multi-day stress runs.

The other important part of the release process is the ability to generate patches for production issues. The ability to ensure quality of such patches and produce all the necessary artifacts in a timely manner is important for anyone running Temporal in production.

Payload Metadata

Cadence stores activity inputs and outputs and other payloads as binary blobs without any associated metadata.

Temporal allows associating metadata with every payload. It enables features like dynamically pluggable serialization mechanisms, seamless compression, and encryption.

Failure Propagation

In Cadence activity and workflow failures are modeled as a single binary payload and a string reason field. Only Java client supports chaining exceptions across workflow and activity boundaries. But this chaining relies on fragile GSON serialization and doesn't work with other languages.

Temporal activity and workflow failures are modeled as protobufs and can be chained across components implemented in different SDKs. For example, a single failure trace can contain a chain that is caused by an exception that originates in activity written in Python, propagated through Go child workflow up to Java workflow, and later to the client.

Go SDK

Temporal implemented the following improvements over Cadence Go client:

Protobuf & gRPC
Synchronous Update (think query that can mutate the workflow state)
No global registration of activity and workflow types
Ability to register activity structure instance with the worker. It greatly simplifies passing external dependencies to the activities.
Workflow and activity interceptors which allow implementing features like configuring timeouts through external config files.
Activity and workflow type names do not include package names. This makes code refactoring without breaking changes much simpler.
Most of the timeouts which were required by Cadence are optional now.
workflow.Await method

Java SDK

Temporal implemented the following improvements over Cadence Java client:

Workflow and activity annotations to allow activity and workflow implementation objects to implement non-workflow and activity interfaces. This is important to play nice with AOP frameworks like Spring.
Polymorphic workflow and activity interfaces. This allows having a common interface among multiple activity and workflow types.
Dynamic registration of signal and query handlers.
Workflow and activity interceptors which allow implementing features like configuring timeouts through external config files.
Activity and workflow type name generation improved
Spring Integration

SDKs not supported by Cadence

Typescript SDK, Python SDK, .NET SDK, PHP SDK

Temporal Cloud

Temporal Technologies monetizes the project by providing a hosted version of the Temporal service. There are over a thousand companies (including SNAP) already using it in production.

Other

We have a lot of other features and client SDKs for other languages planned. You can find us at Temporal Community Forum.

Pack answered 17/4, 2020 at 22:0 Comment(2)

Does the java client use protobuf and gRPC, or just the go client? – Shulins 20/7, 2020 at 20:44

All SDKs use gRPC/ptotobuf as it is the only protocol that Temporal service exposes. In the future we might add HTTP endpoints for certain integrations. If you are asking about application payload serialization then it is pluggable. By default JSON is used, but any other format can be supported. – Pack 20/7, 2020 at 22:23

Overview

Using iWF will let you switch between Cadence & Temporal easily. In addition, iWF will provides a nice abstraction on top of the both and makes your life a lot better.

The fact is both Cadence & Temporal are under active development. You can see they have some different focuses if looking at their road maps. The two projects share the same vision to let everyone rethink about programming models of long-running business.

Tasks across domain+clusters

If you have multiple Cadence clusters, this allows starthing childWF across different clusters and domains.

Support Both Thrift&gRPC

gRPC support is completely done on the server side. Internal traffic is all using gRPC and we are working on letting users migrating from Thrift to gRPC.

Authorization

The permission is based on domain but can be extended. Different from Temporal, the permission policy can be stored within Cadence domain data storage so that you don't have to build another service/storage to manage them. Note that the whole proposal is developed by community member.

Workflow Shadower

Workflow Shadower is built on top of Workflow Replayer to address this problem. The basic idea of shadowing is: scan workflows based on the filters you defined, fetch history for each workflow in the scan result from Cadence server and run the replay test. It can be run either as a test to serve local development purpose or as a workflow in your worker to continuously replay production workflows.

Graceful domain failover

This allows XDC(multiple clusters) mode to reduce the pain of rerun some tasks during failover.

NoSQL plugin model

This allows implementing different NoSQL persistence in a minimum way. By the time writing this post, Temporal haven't started working on it.

MongoDB support

On top of the NoSQL interfaces, MongoDB support is WIP.

Using multiple SQL instances as sharded SQL

This allows user to have a Cadence cluster with a much larger scale. (then using XDC to add more DB instances)

Configuration Storage for Dynamic config

This enables us changing the dynamic configuration(like for ratelimiting) without making any deployment. Just a CLI command can control the behavior of the system.

It's in experiment and still WIP for production ready.

Workflow notification

A WIP eco system project to allow getting notification from Cadence. This is the benefits of Cadence using Kafka to deliver visibility messages. Temporal doesn't use Kafka which will be super difficult to support this feature.

Periodical Healthchecker(Canary) and Benchmark tool and benchmark setup docs

Other small improvements that Temporal is missing

TerminateIfRunning IDReusePolicy
All domain API forwarding policy
Better & cleaner XDC configuration
Tooling to deserialize database blob data ... ...

Denver answered 19/9, 2020 at 0:46 Comment(0)

I'm from the Cadence team at Uber, and I wanted to let you know that Cadence continues to be developed actively by our team. Below is a section of the update that we shared with the Cadence community recently:

We want to reinforce that Uber's Cadence team is committed to the growth and open source development of the Cadence project. Today, Cadence powers 100+ different use cases within Uber and that number grows quickly. Collectively, there are 50M+ ongoing executions at any moment on average and our customers finish 3B+ executions per month. Outside of Uber, we also know that many engineering teams at various companies have already adopted Cadence for their business-critical workflows. We are excited to continue evolving Cadence as an open-source project in a backward-compatible way with an increased focus on reliability, scalability, and maintainability in the near term.

It's probably too early to compare Cadence and Temporal. Still, I have a few ideas around how we can systematically shed light on Cadence's roadmap to ensure all the necessary information is out there to enable such comparisons going forward. I'll update this post with links when we create a page with information about the roadmap.

In the meantime, please let me know if you need further information about Cadence that would be helpful in this context.

Tanah answered 14/4, 2020 at 0:39 Comment(1)

This is basically a non-answer. – Therewithal 3/3, 2021 at 11:12

Temporal.io is a company that has forked cadence project and are now building on top of it - naming it temporal. It is founded by the authors of cadence.

I would suggest using temporal.io as it is under active development

Monteiro answered 11/4, 2020 at 19:31 Comment(1)

Ok thanks. From their slack channel: Temporal uses gRPC instead of thrift which opens up the possibility for lots of things (eg. better authentication support).Temporal Technologies is a startup company (created by the leaders of the original Cadence team) that forked Cadence and is going to offer Cadence (Temporal) as a service for companies. While Uber mostly developped Cadence for themselves, I assume Temporal will want to collect customers from a whole bunch of areas which would mean that enterprise heavy features (like cross-DC replication) might not be the primary (or sole) focus anymore – Isolative 12/4, 2020 at 6:18