In this video, Jeff Winesett discusses using Amazon's simple workflow service, SWF, by providing an example of an image watermarking workflow. SWF helps manage the complex dependencies needed in a business workflow process.
- [Instructor] Another service in the AWS Library that provides a means to achieve decoupling components is called Simple Work Flow, or just SWF. This service is built to help define, manage, and coordinate the tasks that make up a given business workflow. It also handles things such as the overall state of the system. It is intended to deliver all the boilerplate and often complex code needed to manage the dependencies across activities defined in a business workflow process.
A simple ecommerce order process is a common example of a workflow used when introducing the concept of workflow. The workflow begins when a customer places an order, and consists of four tasks. First, ensure the order is valid. If the order is valid, then charge the customer for the order. If the payment is successful, proceed to ship the order and if the order is shipped, have the order saved as complete.
The tasks in this workflow are sequential, and the order of these tasks is important. An order must be verified before the customer is charged. The customer's payment must be successfully processed before an order can be shipped, and an order must be shipped before it can be recorded as complete. Amazon SWF supports distributed processes. This means the tasks defined in an SWF workflow can be carried out at different locations while remaining sequential.
Also, SWF allows these tasks to be decoupled, and if the tasks are implemented using software, they can also be written in different programming languages, and or using different tools. SWF is used to coordinate the communication between them. When creating a workflow with SWF, SWF takes care of the task management, but the application developer configures how the workflow makes decisions about how to proceed once one or more of the workflow tasks has been completed.
These parts are called deciders. The decider helps put the flow in workflow. It responds to results from tasks that have been completed and makes the decisions about what to do next based on configured business rules, and these decisions are triggered based on events assigned by SWF. The other primary piece of the workflow that must be created is the actual carrying-out of the defined task. These are referred to as activity workers.
An activity worker carries out the work assigned by SWF tasks. The decider is responsible for scheduling the work carried out by the activity workers, and these activity workers can be distributed and run from anywhere. To make this a little more concrete, I'll revisit the photo watermarking example I used when I introduced SQS. I did not call it a workflow at the time, but that is, in fact, what was defined. First, a photo is uploaded.
Then it's resized. Then it is watermarked, and finally a notification is sent letting everyone know the process is complete. I showed how this could be architected using SQS. SWF provides another option to implement this workflow. For this simple workflow, a single decider can be used along with three activity tasks, resize, watermark, and notify.
Here's the lifecycle of such a workflow using SWF. The workflow is kicked off when a user uploads a new photo. This photo will trigger the start of the workflow execution action, which is received by the SWF service. The service logs the start of the process, then schedules the first defined task. The decider is configured to poll for decision tasks from SWF. The decider receives the decision task. It then makes the decision to schedule the resize photo activity task.
The decider can also supply any additional information the activity worker needs to complete its task. The decider returns its decision to SWF. SWF receives the decision, logs it, and schedules the resize activity worker, and waits for the task to complete. A listening activity worker that is capable of performing the task receives the task, performs it, and returns the results to SWF.
SWF receives the results, logs them, and schedules the next decision task. The polling decider receives the task, reviews the history of results, and makes the decision to schedule the watermark activity task with any information the watermark activity worker needs to perform the task. It then returns its decision to SWF, which in turn logs it, and schedules the watermark activity task.
A polling watermark activity worker accepts the scheduled task and gets to work creating a watermark, and returning the results to SWF. SWF receives the results, logs them once again in the history, and schedules the next decision task. The decider receives the task, and decides the next step should be to proceed with the notification. It lets SWF know about its decision, and SWF logs it and schedules a notify task.
A polling notification worker picks up the scheduled task, performs it, and returns the results. At this point, the results are logged once again by SWF. Another decider task is scheduled, and this time the decider sees the final task has completed and it makes the decision to close the workflow execution, and sends that decision back to SWF. SWF then closes out the workflow execution and archives the history for future reference.
The watermarking app is a very simple workflow. Many business applications are more complex. SWF can really help to simplify the coordination and complexities of more sophisticated, distributed, and even parallel workflows. And as all the activity workers are self-contained and independent from one another, SWF can help create complex workflows with decoupled components. Decoupling components lesson number two: consider using SWF to help with more complex workflows, and to help keep components independent from one another.
- Benefits of cloud services
- Making architectures scalable
- Examining cloud constraints
- Virtual servers, EC2, and Elastic IP
- Using the Amazon machine image
- Elastic load balancing
- Using CloudWatch for monitoring
- Security Models
- Elastic block storage
- S3, CloudFront, and Elastic Beanstalk
- Handling queues, workflows, and notifications
- Caching options and services
- Identity and access management
- Creating a custom server image
- Application deployment strategies
- Serverless architectures