Awfully Thorough Guide to Choosing the Best Serverless Solution, Part 2.1 : AWS Step Functions
So far, we’ve examined FaaS offerings from four big players and saw a clear winner, AWS Lambda. In this post we’ll find out whether Amazon will also be a winner when it comes to Serverless Applications.
What is a Serverless Application and Why Should I Care?
“A serverless application is a combination of Lambda Functions, event sources and other resources that work together to perform tasks. Note that a serverless application is more than just a Lambda function — it can include additional resources such as APIs, databases and event source mappings.” — that’s how Amazon defines it.
The most important word missing from this description is “state”. Lambda, or any other function, is stateless by definition and thus is obviously very limited by its functionality. But what if you want to stitch together services such as AWS Lambda and Amazon DynamoDB into some feature-rich application? How you can clue and orchestrate all the services?
Serverless applications allow you to define and handle global application states that are fully accessible by every single function. This is a serious boost to what can be done when it comes to serverless.
But serverless applications are not only about state. Building serverless applications can generally be divided into two major steps: first, developing an application consisting of small lightweight building blocks that work together to implement some business logic, often called “serverless workflow,” and second, deploying an application to cloud using infrastructure-as-a-code techniques.
To handle the first step, cloud vendors created serverless orchestration services such as AWS Step Functions, Azure Logic Apps and some others.
The latter task is much more complicated than deploying a single function. There are fairly good comparison posts out there that review the various deployment frameworks for Serverless Applications (and they will be listed in a separate section), so this post will review existing solutions for developing and orchestrating serverless applications.
With that in mind, let’s get started.
Serverless Orchestration: AWS Step Functions
AWS Step Functions lets you coordinate multiple AWS services into serverless workflows so you can build and update apps quickly. Workflows are made up of a series of steps, with the output of one step acting as input into the next. Step Functions translate your workflow into a state machine diagram that is easy to understand, easy to explain to others and easy to change
Benefits and Use Cases
AWS Step Functions makes it easy to coordinate the components of distributed applications as a series of steps in a visual workflow. You can quickly build and run state machines to execute application steps in a reliable and scalable fashion. That being said, it’s not yet possible to visually design workflows (while Azure Logic Apps and IBM Node-Red both offer the ability to design workflows visually). Instead, you can use a JSON for design and use the visualization tool to validate the design visually.
The main benefit of such an approach is improved resiliency of your application. AWS Step Functions manages state, checkpoints and restarts for you, ensuring your application executes in order and as expected. Built-in try/catch, retry and rollback capabilities deal with errors and exceptions automatically. All this makes Step Functions an excellent choice for business-critical flows such as payments and subscriptions.
Another typical use case for Step Functions is data processing and machine learning training workflows. Step Functions can help ensure long-running, multiple ETL jobs execute in order and complete successfully, instead of manually orchestrating those jobs or maintaining a separate application.
Tooling and Debugging
As mentioned above, AWS Step Functions does not support visual workflow design and you should leverage the Amazon States Language (ASL), a JSON-based, structured language used to define your state machine.
The fundamental entity of ASL is state, which defines the resource (i.e., which Lambda) to run as well as what to do upon various conditions of resources executions results (i.e., failures, timeouts, and so on).
That’s right, you need manually create cumbersome JSON files with compacted flows in a small window inside the AWS web form. Far from being an ideal approach. On the bright side is the visual workflow that reflects the JSON and can be retrieved by pressing a “Refresh” button.
Also, there are some out-of-the-box code snippets you can use.
After you are done with the state machine, you need to manually update the ARNs of the services your state machine is going to use. Did I already mention the word “cumbersome?”
For testing and development purposes, you can install and run Step Functions on your local machine, and it will also save you the costs of making state transitions online. With a Step Functions Local Docker Container packed with all the dependencies and configuration, you can start an execution on any machine and invoke Lambda Functions, both in AWS and when running locally. Here’s the link to the docker hub. Unfortunately, the AWS toolkit, which was developed for most of the popular IDEs, does not support Step Functions.
Now how can you keep your developed state machine, a critical part of your app logic, alongside all the other source code? You can do it with AWS’ own SAM model, or, if you are using a Serverless.com framework, with this plugin. This approach also makes Step Functions versioning and deployment through various CI/CD systems pretty easy.
Official AWS documentation states that the following services are supported and can be integrated into the Step Functions flow:
Monitoring and Logging
As with any other AWS service, Step Functions has its own dedicated CloudWatch logging groups. In addition, there is a comprehensive Executions console, where every execution of the state machine can be tracked and monitored.
You can see the related resource, input, output and exceptions of every single state in the state machine, as well as single execution event history.
Performance and Scaling
AWS Step Functions places limits on the size of state machine parameters by default, such as the number of API actions you can make during a certain time period and the number of state transitions processed per second. These limits help prevent a misconfigured state machine from consuming all resources of the system. If the default limits do not meet your needs, you can request a limit increase by contacting AWS Support.
As of May 2018 Step Functions supports throughput of 1,000 state transitions per second with burst capacity of 5,000 state transitions. The default start rate for AWS Step Functions state machine executions is 200 per second, with burst capacity of up to 1,000 starts in select regions (U.S. East (Northern Virginia), U.S. West (Oregon), and EU (Ireland)).
Step Functions uses IAM to control access to other AWS services and resources — a pretty standard approach for every AWS service. You can read more here.
The Step Functions pricing model is based on state transition counts. State transition happens every time a step of your workflow is executed. You are charged for the total number of state transitions across all your state machines, including retries. The free tier of Step Functions includes 4,000 free state transitions per month. For details, see the Step Functions pricing examples.
Please remember that since Step Function is just a layer on top of other AWS services, you may incur additional charges if the operation of your application workflow utilizes other AWS services or transfers data.
Wrap Up and Further Reading
While providing an essential orchestration level for serverless architecture can ease things a lot on the developer’s side, AWS Step Functions is still far from being complete. The main drawback is the lack of the state machine visual editor (you might this 3rd party add-on to draw.io useful though).
As for further reading, you might want to read the official AWS Best Practices for Step Functions, Hitchhiker’s Guide to AWS Step Functions by Yan Cui or a handful of Serverless Data Processing with AWS Step Functions — An Example blog posts with a full source code provided.
Next Post in a Series