We launched AWS Step Functions at re:Invent 2016, and our customers took to the service right away, using them as a core element of their multi-step workflows. Today, we see customers building serverless workflows that orchestrate machine learning training, report generation, order processing, IT automation, and many other multi-step processes. These workflows can run for up to a year, and are built around a workflow model that includes checkpointing, retries for transient failures, and detailed state tracking for auditing purposes.
Based on usage and feedback, our customers really like the core Step Functions model. They love the declarative specifications and the ease with which they can build, test, and scale their workflows. In fact, customers like Step Functions so much that they want to use them for high-volume, short-duration use cases such as IoT data ingestion, streaming data processing, and mobile application backends.
New Express Workflows
Today we are launching Express Workflows as an option to the existing Standard Workflows. The Express Workflows use the same declarative specification model (the Amazon States Language) but are designed for those high-volume, short-duration use cases. Here’s what you need to know:
Triggering – You can use events and read/write API calls associated with a long list of AWS services to trigger execution of your Express Workflows.
Execution Model – Express Workflows use an at-least-once execution model, and will not attempt to automatically retry any failed steps, but you can use Retry and Catch, as described in Error Handling. The steps are not checkpointed, so per-step status information is not available. Successes and failures are logged to CloudWatch Logs, and you have full control over the logging level.
Workflow Steps – Express Workflows support many of the same service integrations as Standard Workflows, with the exception of Activity Tasks. You can initiate long-running services such as AWS Batch, AWS Glue, and Amazon SageMaker, but you cannot wait for them to complete.
Duration – Express Workflows can run for up to five minutes of wall-clock time. They can invoke other Express or Standard Workflows, but cannot wait for them to complete. You can also invoke Express Workflows from Standard Workflows, composing both types in order to meet the needs of your application.
Event Rate – Express Workflows are designed to support a per-account invocation rate greater than 100,000 events per second. Accounts are configured for 6,000 events per second by default and we will, as usual, raise it on request.
Pricing – Standard Workflows are priced based on the number of state transitions. Express Workflows are priced based on the number of invocations and a GB/second charge based on the amount of memory used to track the state of the workflow during execution. While the pricing models are not directly comparable, Express Workflows will be far more cost-effective at scale. To learn more, read about AWS Step Functions Pricing.
As you can see, most of what you already know about Standard Workflows also applies to Express Workflows! You can replace some of your Standard Workflows with Express Workflows, and you can use Express Workflows to build new types of applications.
Using Express Workflows
I can create an Express Workflow and attach it to any desired events with just a few minutes of work. I simply choose the Express type in the console:
Then I define my state machine:
I configure the CloudWatch logging, and add a tag:
Now I can attach my Express Workflow to my event source. I open the EventBridge Console and create a new rule:
I define a pattern that matches
PutObject events on a single S3 bucket:
I select my Express Workflow as the event target, add a tag, and click Create:
The particular event will occur only if I have a CloudTrail trail that is set up to record object-level activity:
Then I upload an image to my bucket, and check the CloudWatch Logs group to confirm that my workflow ran as expected:
As a more realistic test, I can upload several hundred images at once and confirm that my Lambda functions are invoked with high concurrency:
I can also use the new Monitoring tab in the Step Functions console to view the metrics that are specific to the state machine:
You can create and use AWS Step Functions Express Workflows today in all AWS Regions!
from AWS News Blog https://ift.tt/2Rfs5FS