2

We're currently investigating the use of Amazon SWF to take care of the longer running jobs in our backend. Our architecture consists of the typical stack:

client (web/android/iOS)
----
API/Worker (Elastic Beanstalk)
----
DB (RDS)

I would like to know what would be the best place to put the SWF-decider logic. A separate EC2 instance, inside the API component, or would it make sense to separate it in another EBS-worker?

Pepster
  • 1,996
  • 1
  • 24
  • 41

2 Answers2

0

You can deploy your deciders to the same EC2 instances as your activity workers. However, I would not recommend deploying the API service and all the workers to the same instances.

In case of a spike in your workflows your SWF workers could scale independently of your API service and vice versa.

I think creating a separate Bean Stalk Configuration for your workers would make sense.

Weiwu
  • 41
  • 3
  • Thanks. I think my question is more about how to hook a decider up to the API. Currently the API is using SQS to signal EBS-workers to do stuff. Hence this stuff is making decisions, so it is eligible to be replaced by SWF. But I wonder what would be the best place to put the decider logic... – Pepster Nov 26 '14 at 08:06
  • If you're using the Flow framework you annotate your workflow implementation with @ Workflow (Decider) and @ Activity (Worker) so Flow will poll SWF and check if there are Decision or Activity tasks. So your decider is actually created by Flow based on your workflow implementation. Your API should only call the method that is annotated with @ Workflow and Flow will automatically start the workflow for you (It calls the StartWorkflowExecution API in the background). Here is an [example](http://docs.aws.amazon.com/amazonswf/latest/awsflowguide/getting-started-example-helloworldworkflow.html) – Weiwu Nov 27 '14 at 19:07
0

Have you considered using the EC2 container service? I would advise using a separate container for each decider and worker.

neeraj salpekar
  • 1
  • 1