Serverless Step Functions: Avoid Leaky Abstractions

I have some exciting news to share with you about the Serverless Step Functions plugin.

One of the main pain points of using the plugin was that you needed to use fully-formed ARNs. We addressed this in v1.18.0 by supporting CloudFormation intrinsic functions

Fn:GetAtt

and

Ref

. This makes it possible for you to reference a local function instead.

functions:
  hello-world:
    handler: hello-world.handler

stepFunctions:
  stateMachines:
    myStateMachine:
      definition:
        StartAt: HelloWorld
        States:
          HelloWorld:
            Type: Task
            Resource:
              Fn::GetAtt: [HelloDashworldLambdaFunction, Arn]
            End: true

But this is still a leaky abstraction - you have to know how the Serverless framework converts local function names into CloudFormation logical IDs.

Newcomers would often get confused here.

“How did you get the logical ID HelloDashworldLambdaFunction from hello-world?”

I can hardly blame them for not knowing. This is an implementation detail in the Serverless framework, one that you shouldn’t have to care about!

Which is why I’m really happy to tell you that, as of v2.2.0 you can reference local functions using their local names in the state machine definition.

functions:
  hello-world:
    handler: hello-world.handler

stepFunctions:
  stateMachines:
    myStateMachine:
      definition:
        StartAt: firstTask
        States:
          firstTask:
            Type: Task
            Resource:
              Fn::GetAtt: [hello-world, Arn]
            Next: secondTask
          secondTask:
            Type: Task
            Resource: arn:aws:states:::lambda:invoke
            Parameters:
              FunctionName:
                # you can use Ref to get the function name
                Ref: hello-world
              Payload:
                answer: 42
            Next: thirdTask
          thirdTask:
            Type: Task
            Resource: arn:aws:states:::lambda:invoke.waitForTaskToken
            Parameters:
              FunctionName:
                # you can also use Fn::GetAtt to get the ARN
                Fn::GetAtt: [hello-world, Arn]
              Payload:
                token.$: $$.Task.Token
            End: true

In the above example, when we reference the local function

hello-world

we no longer need to use its CloudFormation logical ID

HelloDashworldLambdaFunction

As you can see from the example, it applies when you use either

Ref

Fn::GetAtt

functions in a

Task

state. And it applies to all 3 ways of invoking a Lambda function from a

Task

state.

Hi, my name is Yan Cui. I’m an AWS Serverless Hero and the author of Production-Ready Serverless. I have run production workload at scale in AWS for nearly 10 years and I have been an architect or principal engineer with a variety of industries ranging from banking, e-commerce, sports streaming to mobile gaming. I currently work as an independent consultant focused on AWS and serverless.

You can contact me via Email, Twitter and LinkedIn.

Check out my new course, Complete Guide to AWS Step Functions.

In this course, we’ll cover everything you need to know to use AWS Step Functions service effectively. Including basic concepts, HTTP and event triggers, activities, design patterns and best practices.

Get your copy here.

Come learn about operational BEST PRACTICES for AWS Lambda: CI/CD, testing & debugging functions locally, logging, monitoring, distributed tracing, canary deployments, config management, authentication & authorization, VPC, security, error handling, and more.

You can also get 40% off the face price with the code ytcui.

Get your copy here.

Originally published at https://theburningmonk.com on July 31, 2019.