Try temporal.io. It is just a Java library without any code generation and AspectJ. It also allows to write synchronous code while Flow was only asynchronous.
240 karma · joined January 19, 2017
1. Need to keep the workers with old code around. It might be solved for some languages like Java by dynamic code loading, but it is still pretty complex. For long-running workflows dozens of changes can happen during their lifetime, requiring dozens of versions to be present at runtime.
2. When a bug is fixed the old versions do not get the fix as they are inherently immutable. Thus a workflow that runs for a month and has started yesterday is still going to experience a bug that was fixed today.
The approach that Temporal promotes is to version each piece of code independently when needed. This way, there is only one version of the entire code in production to maintain, and bug fixes can be deployed any time and apply to all the open workflows that didn't reach the code that was fixed.
At the same time I witnessed hundreds of cases when developers spent inappropriate amount of time developing "abstractions into application layer" instead of the business logic.
It is like writing assembler code against raw Linux kernel systems calls while Python is available and complaining that Linux is too hard to use.
Look at the temporal.io samples which give you completely different view of how such code should look like. For example the money transfer sample (taken from https://github.com/temporalio/java-samples/blob/master/src/m...):
```
public class AccountTransferWorkflowImpl implements AccountTransferWorkflow {
private final ActivityOptions options =
ActivityOptions.newBuilder().setStartToCloseTimeout(Duration.ofSeconds(5)).build();
private final Account account = Workflow.newActivityStub(Account.class, options);
@Override
public void transfer(
String fromAccountId, String toAccountId, String referenceId, int amountCents) {
account.withdraw(fromAccountId, referenceId, amountCents);
account.deposit(toAccountId, referenceId, amountCents);
}
}
You could make the same argument about SQL databases. Why do you need to understand their architecture, learn arcane SQL syntax, and learn to operate them? Instead, your program could write and read files directly from disk. But you still choose to use the DB as it has hundreds of man-years invested in it and gives you a higher level of abstraction.
Think about SWF and its newest incarnation in the form of temporal.io as a higher-level way to write task orchestrations. It requires some learning but allows you immediately to leverage dozens of man-years invested in the technology.
Independently of my opinion on the standard I think the best implementation platform for it would be temporal.io.
AMA.
BTW. You can AMA about the technology here.
Cadence is used in production by over 100 teams at Uber and multiple outside companies. For example here is a presentation that describes how HashiCorp relies on Cadence for the new version of its Consul product: https://www.hashicorp.com/resources/making-multi-environment.... The Cadence related part starts at 17:30.
My opinion is that DOMAIN specific languages are awesome when they are used for a specific narrow domain. For example AWS CloudFormation template is a DSL for a cloud deployment. If This Then That, also known as IFTTT is another good example of a narrow workflow definition.
At the same time a generic turning complete language in JSON/YAML/XML always starts simple but ends up as a complete mess. See https://mikehadlow.blogspot.com/2012/05/configuration-comple.... Any programming language is much better for writing complex programs. The problem is that most existing workflow/orchestration systems force developers to use unnatural programming patterns and libraries to make the code fault tolerant. Cadence is an attempt (pioneered by my team at AWS Simple Workflow and later picked up by Azure Durable Functions) to implement workflows as natural programs without much boilerplate concepts and code.
Think, why nobody tries to write complex backend programs in JSON? The reason that programming languages have well defined ways to deal with complexity. JSON based languages are good for limited domains, but anything complex makes them unusable. I've seen it hundreds of times already when DSL is abused and developers hate it.
So most of the Cadence workflows are written directly as Go/Java code. But when DSL is appropriate it can be added trivially by interpreting it by the worker code.
>Again - the same question: wouldn't it have been better to have a uniform declarative JSON ?
Again, declarative JSON is declarative only in narrow domains. The generic workflow definition language in JSON works only for very simple scenarios and is harder to write and debug then Go/Java code.
(2) It depends. Nothing prevents a workflow writer from checkpointing the state explicitly (by calling continue as new). Infinitely running workflows do it periodically. But having the events history is awesome for rollbacks. For example in Cadence it is possible to rollback a bad change and automatically rollback the state of all your workflows to the good state. In database world a change that corrupted the state is much harder to deal with.
(3) The experience shows that the determinism requirement while requires some learning is not that hard to deal with. But the superior programming model it allows is liked by users.
It allows:
Integrate any DSL without modiying the core service. Internally at Uber there are at least half dozen DSLs running on top of it.
It allows to write code that hides all the complexity that leads to the mess of queue + db implementations. The beginning of this talk explains the idea: https://youtu.be/BJwFxqdSx4Y
The gist of it is that you write just your business logic without thinking about callbacks and storage.
I recommend looking at the Cadence samples to get the taste of it. Join the Cadence Slack channel if you have any specific questions: https://join.slack.com/t/uber-cadence/shared_invite/enQtNDcz...
This is the direction the Cadence is going. We are planning to add support for integrating custom DSLs easily, but maintaining the core code based libraries.
BTW: If anyone is interested on running the Step Functions DSL on top of Cadence contact the Cadence team. We could work together to get it implemented.
Actually at Uber large number of services are being migrated from Python/Celery to Go/Cadence.
Cadence is also more scalable supporting tens of thousands events per second and hundreds of millions of open workflows.