AWS Serverless Application Model (AWS SAM) は先頃、AWS Step Functionsステートマシンをサポートした。新しいAWS::Serverless::StateMachineリソースタイプを使用すると、開発者はSAMテンプレート内または別のファイルで状態マシンを定義できるため、ワークフローオーケストレーションをサーバレスアプリケーションの統合部分としてプロビジョニングできる。
AWS Serverless Application Model (AWS SAM) はオープンソースのフレームワークで、AWSのインフラストラクチャをコードサービスCloudFormationとして拡張する「シンプルでクリーンな」ショートハンド構文を提供し、サーバレスアプリケーションの構築を容易にする（以前の記事）。これには、一般利用可能になった「サーバレスアプリケーションを作成、開発、デバッグ、デプロイするためのローカルツール」を提供する、AWS SAM CLIが付属している。
AWS Step Functionsはサーバレスのワークフローオーケストレーションサービスであり、「AWS Lambda関数と複数のAWSサービスをビジネスクリティカルなアプリケーションにシーケンス化」できる。Step Functionsステートマシンの実行は、状態、エラー処理、および再試行ロジック（以前の記事）を自動的に管理しながら、最大1年間実行できる。
Rob Sutter氏の紹介ブログ投稿で概説されているように、AWS::Serverless::StateMachineリソースタイプを介したStep Functionsの新しいAWS SAMサポートは、サーバレスアプリケーションでのワークフローの定義を簡素化する。ワークフロー実行のロギングやイベントベースのトリガーなどの構成オプションのショートハンド構文を提供するだけでなく、これにより、SAMポリシーテンプレートを使用して、ワークフローのアクセス許可を対象のアプリケーションで使用されるリソースのみに絞り込むことができる。これにより、AWS Serverless Application Repository（以前の記事）からアプリケーションをデプロイするときに、対象範囲外のIAMアクセス許可に対する顧客の承認を見送ることができる。
彼のサンプルテンプレートは、DynamoDBテーブルをプロビジョニングする。このテーブルは、サービス統合を介して、Step FunctionsステートマシンからPutItem APIアクションで参照され、ワークフローの実行に関する情報を格納する。また、ポリシーテンプレートからも参照されるため、すべてのリソースを単一のアプリケーションとしてまとめてプロビジョニングできるようにする:
Resources:
SAMTable:
Type: AWS::Serverless::SimpleTable
SimpleStateMachine:
Type: AWS::Serverless::StateMachine
Properties:
Definition:
StartAt: FirstState
States:
FirstState:
Type: Pass
Next: Write to DynamoDB
Write to DynamoDB:
Type: Task
Resource: arn:aws:states:::dynamodb:putItem
Parameters:
TableName: !Ref SAMTable
Item:
id:
S.$: $$.Execution.Id
ResultPath: $.DynamoDB
End: true
Policies:
- DynamoDBWritePolicy:
TableName: !Ref SAMTable
特に、ステートマシンは、前の例のように、JSONまたはYAMLベースのSAMテンプレートのDefinitionプロパティを介してインラインで定義できるが、以下に示すように、Amazon S3 URIまたはローカルファイルパスのDefinitionUriプロパティを介しても定義できる。いずれにしても、DefinitionSubstitutionsプロパティでは、ステートマシン内の${dollar_sign_brace}表記で一致する変数定義を置き換えるキーと値のペアのマップを指定できる:
StockTraderStateMachine:
Type: AWS::Serverless::StateMachine
Properties:
DefinitionUri: statemachine/stockTrader.asl.json
DefinitionSubstitutions:
StockCheckerFunctionArn: !GetAtt StockCheckerFunction.Arn
StockSellerFunctionArn: !GetAtt StockSellerFunction.Arn
StockBuyerFunctionArn: !GetAtt StockBuyerFunction.Arn
DDBPutItem: !Sub arn:${AWS::Partition}:states:::dynamodb:putItem
DDBTable: !Ref TransactionTable
AWSコミュニティのヒーローであるBen Kehoe氏は、このアーキテクチャ上の選択をツイートで取り入れた:
皆さん、よく聞いてください。これは、DSLデプロイAPI（CodeBuild、CodePipeline、SSM Automationドキュメントなど）がどのように機能するかを示しています。コンテンツを独自のファイルで定義し、置換を使用してテンプレートから参照を挿入します。私はこのリリースをとても楽しみにしています！
AWS::Serverless::StateMachineによって提供される追加の簡素化は、ワークフローの実行を開始できるイベントソースの構成と、ワークフローの実行履歴をキャプチャするログの宛先の構成をカバーしている。どちらも概念的には、これらのプロパティが他のリソースタイプに実装される方法と同様に機能する。
関連するニュースとして、AWSチームは先頃、Visual Studio Codeを介したStep Functionsワークフローで「定義、視覚化および作成」するサポートを追加した。AWS Toolkit for Visual Studio Codeも、起動構成を介してSAMアプリケーションをデバッグする機能を得た。AWS Step Functions自体は最近新しくAWS CodeBuildとのサービス統合をした。これは、Step Functionsを介して複雑なリリースプロセスをサポートする新しいAWS CodePipelineのアクションタイプによって補完される。これらの更新を組み合わせることで、開発者は、MicrosoftのGitHub Actionsとは異なり、きめ細かな継続的デリバリー機能を使用してソフトウェア開発ワークフローを自動化およびカスタマイズできる。
AWS SAMよりもServerless Frameworkを好む開発者は、Serverless Step Functionsプラグインを使うことができる。Microsoft Azureは、Visual Studio CodeのAzure Logic Appsワークフロー定義を作成および管理するためのデザイナファーストの宣言型開発者エクスペリエンスも提供する。対照的に、Azure Durable Functionsは、ステートフルワークフローにコードファーストの命令型オーケストレーションを提供する。Google Cloud PlatformのワークフローオーケストレーションサービスであるCloud Composerは、オープンソースのApache Airflowエンジンの上に構築されており、Pythonベースのコードによる構成を使用する命令型ワークフロー定義を備えている。
AWS Serverless Application Modelのドキュメントには、AWS SAM仕様のリファレンス、SAM CLIコマンドリファレンス、SAMポリシーテンプレートなどの開発者ガイドが含まれている。サポートはGitHubリポジトリとSlackチャネルを介して提供される。AWS SAMは、プロビジョニングされたAWSサービスの通常の使用量ベースの料金を超える追加料金なしで提供される。