AWS SWF good practice for sequential activities

2
votes

I'm kinda of newbie to AWS SWF. Still under learning and document crunching phase. Just come up with a silly question. For a use case that a sequential workflow, instead of defining a series of activities that will be executed in sequence by decider, should we just put all implementation into a big activity? Since each task in a workflow charges at $0.000..25, this way will save more money for large scale.

For this kinda of use case, What's a good reason to declare a series of small activities in a guaranteed-sequential workflow execution?

1
amazon-web-servicescloudamazonamazon-swf
If you can put everything in a single activity, don't use SWF. That doesn't make any sense. What is it providing you? Just use SQS or SNS and save yourself some headaches. If you're not going to be making decisions as you progress through the workflow, the complexities of using SWF are just wasted effort for you. – xaxxon
For SQS, according to aws.amazon.com/sqs/faqs, each message is delivered “at least once”, and so can give duplications, which might not be easy to handle at the application layer in a distributed/no-single-point of failure way. SNS itself uses a push system which again might not appropriate/possible in all cases. – Michal Charemza

1 Answers

3
votes

If your use case is actually simple, you can declare a big activity (what is cheaper, as you stated), but in general the benefits of using a set of small activities are:

  • You can run a particular step (one of these activities) in a different set of workers (via a different task list), with specialized resources. For instance, you could run two farm of workers: one "regular" farm for general purposes, and one "Big CPU" farm for computing-intensive operations; all part of the same workflow execution.
  • Depending on how you execute activities (using Flow or your own worker runtime), you could retry failed activities separately.
  • You could version your activities independently, instead of just one version for the whole workflow.
  • If the workflow evolves, it would be easier to extend or update using a set of activities (one of the building blocks of your workflow).
  • If in the future you need to act after a workflow signal, you would have a hard time decoupling your logic to support it.
  • Atomic activities are potentially reusable by other workflow types (or even the same workflow: for instance, sending an email at the beginning and the end of the workflow).