AWS Step Functions

• Provide a visual interface for serverless applications, which enables you to build, and run service application as a series of steps.
• Each step in your application, execute in order, as defined by your business logic.
• The output of one step may act as an input of next step
• Step functions provide orchestration for server less applications
• Manage the logic of your application
• If our application has many Lambda Functions for a task, then we may require orchestration, which includes sequencing, error handling, and retry logic, so your application, execute in order, and as expected.
• Step functions also log the state of each step, so when things go wrong, you can diagnose and debug problems quickly.
• Step functions consist of state machines and tasks and state machine is workflow itself and task is a single step or single unit unit of work that makes up the workflow.
• Step functions has different kind of workflows
• Sequential workflow in which steps always happen one after the other.
• The steps always run in a sequence and no two steps can run together at same time.
• Output of one step is input of next step.
• Each of the steps are fulfilled by a different lambda function.
• Parallel workflow
• Parallel tasks run together and converge into a single step, for example, three tasks, running together and saving data into database.
• Each step is handled by a lambda function, which needs to be coordinated.
• Branching workflow
• It starts as a sequential workflow
• We have selective course of action or tasks based on the type of response.
• Not all steps one in this type of workflow.
• For example, when all steps are passed will notify success else we notify failure.
• Different tasks are managed by different lambda functions, and the whole thing is coordinated by step function.
• For creating a step function, go to step functions in AWS console
• Open menu and select state machines and create a state machine.
• Select run a sample project.
• We can run any sample project but let’s select a simple one called as “job Poller”.
• In bottom we can see definition of our state machine or workflow in left-hand side.
• State machines are defined using Amazon state language.
• On the right hand side, we get visual representation of our state machine.
• Select next, and we see deployment page.
• Select deploy resources.
• Once the deployment completes, we can start execution of our state machine.
• We can see the progress of our state machine.
• The task in progress is shown in blue.
• The task completed is shown in green.
• Any task that fails is shown in red.
• We can see details of tasks once we select the tasks, and we can see inputs and outputs of these.
• We can see the execution event history also below the tasks.
• Types of step functions State machines.
• Step functions provide various types of state machines that feature different workflows to cater to variety of tasks that you would like to orchestrate.
• The kind of tasks you are orchestrating determine the type of workflow you should use.
• Standard workflows
• Long-running, durable, and auditable workflows that may run for up to a year. Full  execution history available for up to 90 days after completion.
• At most ones model
• Tasks are never executed more than once, unless you explicitly specify retry actions.
• Non Idempotent actions
• When processing payments, you only want a payment to be processed once, not multiple times.
• Change in state
• A request is non idempotent if it always causes a change in state. Example sending the same email multiple times causes a change in state because you end up with multiple emails in your inbox.
• Express workflows
• Short lived
• Great for high volume, event processing is types workload.
• Time limit is up to 5 minutes.
• At least one model
• Ideal if there is a possibility that an execution might be run more than once or you require multiple concurrent execution.
• Idempotent actions
• For Example, transforming input data and storing the result in Dynamo DB.
• Identical request
• Has no side-effect
• A request is considered Idempotent, if an identical request can be made once or several times in a row with no additional side-effects example reading data from a database or S3 bucket.
• Two types of express workflows
• Synchronous workflow
• Begins a workflow
• Wait until it completes
• Returns the result
• Great for operations that are performed one at a time. The workflow must complete before the Next step begins.
• Example, Your customer must complete payment before sending order.
• Face to face conversation where journalist asks a question and waits for the response of panellist before moving to next question.
• Asynchronous Express Workflow
• Begins a workflow
• Confirms the workflow has started
• The result of the workflow can be found in the cloud watch logs.
• Great, if services or operations don’t depend on the completion and result of your workflow.
• Example, you need to send an email to a co- worker providing a link to a shared folder. You send the email and then move to the next task without waiting for their response.
• Asynchronous workflows often run in the background, while synchronous workflows, hold you up until they are complete.