The article is pretty naive. It writes code against the low level API which was never intended for workflow writers and then complains that it is too complicated. He had to use the high level library (https://docs.aws.amazon.com/amazonswf/latest/awsrbflowguide/...) instead.

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);
     }
  }

```

The main thing I liked about SWF was that the entire workflow was represented in my own code. We ended up cloning the parts of SWF we used when we had to deploy outside AWS. The decider/actor pattern is a great pattern and I'd definitely use it again.

However, as you say, the 'Simple' part is definitely a misnomer.

Look at temporal.io. I believe we managed to get rid of the original SWF rough edges while maintaining the "workflow as code" approach. And the best part is that it is open source and you can run it anywhere yourself.

What is the relationship between this project and uber/cadence? I see you have worked on both and they seem very similar/the same.

Thanks for the link, I wish I'd known about that before. I'll be sure to consider that for my next project.