AWS Data Management
AWS Solutions Architect Associate Level Certification Course - Part 3 of 3
Having completed parts one and two of our AWS certification series, you should now be familiar with basic AWS services and some of the workings of AWS networking. This final course in our three-part certification exam preparation series focuses on data management and application and services deployment.
Who should take this course?
This is an advanced course that's aimed at people who already have some experience with AWS and a familiarity with the general principles of architecting cloud solutions.
Where will you go from here?
The self-testing quizzes of the AWS Solutions Architect Associate Level prep materialis a great follow up to this series...and a pretty good indicator of your readiness to take the AWS exam. Also, since you're studying for the AWS certification, check out our AWS Certifications Study Guide on our blog.
Amazon simple workflow services as AWS describes, a fully managed state tracker and task coordinator in the cloud. That is, if your project relies on multiple distributed applications launching critical tasks in coordination with each other, you'll need to know that they're actually communicating properly with each other and getting their work done. Since the Solutions Architect associate exam doesn't address SWF in any great detail, we'll make due here with a broad overview rather than a full demonstration. Let's imagine we're running an online digital photo printing service, who's workflow can be broken down into individual activities, or tasks. There's the website form that allows the customer to upload his photos, the software that processes customer payment, the printing module, and the software confirming that shipping is complete. If every task except one succeeds, say no image is actually printed, the whole process is a failure.
You've billed your customer for a blank piece of photographic paper. To help, SWF divides operations into elemental parts, domains, workflows, activities, and actors. Domains are containers for holding workflows. You can place multiple workflows in a single domain but they can't communicate between domains.
Workflows are the full start to finish processes that are made up of individual activities. Activities are the individual steps, image printing or credit card processing for instance, that make up a workflow. And actors are the software or human workers actually carrying out the activities. Shipping fulfillment and a browser-based order form are two examples.
Now plugging these elements back into our imaginary photo business, the entire process is called a workflow, which itself is contained within a domain. The website upload page, payment processing software, printer, and shipping department are all actors. While the upload, payment processing, printing, and shipping processes are all activites. It's SWF's job to coordinate all these elements, assign them unique identifiers, make sure that each does what it's supposed to do, and provide reports and tracking audits to you, the boss. SWS provides a sample walkthrough that will create an actual working domain and workflow that you can use to better understand how the system works. We'll just quickly go through some of the steps necessary to build our own workflow manually. We'll start by registering a new domain. Click on manage domains at the top right, then register new. Let's call our domain printed. We'll set the workflow execution retention period to 30 days. From here on in we'll need to make sure we're working with the right domain. Make sure that the domain drop down menu at the top left is set to our printed domain. Now we'll register a new workflow type. Clicking on the quick link at the bottom left, we'll call our workflow new order. Give it a version number of 1.0, create a default task list called, say, tasks. And set both the default execution start to close and task start to close timeouts at 300 seconds. We won't enter any description, but we will click review, then register workflow. Now we'll register an activity type. We'll give it some name and version, much like we did with our workflow registration.
We'll assign the task to a default task list. In our case, we'll enter the name of the list we created with our workflow, tasks. We could set new timeout values that would override the domain values we set previously, or we can leave these blank and rely on our domain settings.
We'll review and register. Obviously we would have to create a new activity type to represent each step in our workflow.
But I expect that you'll get the picture already. To start a new execution, we could type the letter n, the first letter of our workflow name, new order, to populate the name box enter 1.0 as the version number, and assign say 100 for our ID. We'll click through to complete our setup, which is successful. Although of course nothing will actually happen, because this is after all an imaginary process.
David taught high school for twenty years, worked as a Linux system administrator for five years, and has been writing since he could hold a crayon between his fingers. His childhood bedroom wall has since been repainted.
Having worked directly with all kinds of technology, David derives great pleasure from completing projects that draw on as many tools from his toolkit as possible.
Besides being a Linux system administrator with a strong focus on virtualization and security tools, David writes technical documentation and user guides, and creates technology training videos.
His favorite technology tool is the one that should be just about ready for release tomorrow. Or Thursday.