paint-brush
Serverless Step Functions: Avoid Leaky Abstractions by@theburningmonk
1,011 reads
1,011 reads

Serverless Step Functions: Avoid Leaky Abstractions

by Yan CuiAugust 31st, 2019
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Yan Cui is an AWS Serverless Hero and the author of Production-Ready Serverless. He explains how the Serverless framework converts local function names into CloudFormation logical IDs. As of v2.2.0 you can reference local functions using their local names in the state machine definition. This applies to all 3 ways of invoking a Lambda function from aTask state. The new plugin is available now for pre-emptive use only in v1.18.0.0. You can also get 40% off the face price with code ytcui.

People Mentioned

Mention Thumbnail

Company Mentioned

Mention Thumbnail
featured image - Serverless Step Functions: Avoid Leaky Abstractions
Yan Cui HackerNoon profile picture

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

One of the main pain points of using the plugin was that you needed to use fully-formed ARNs. We addressed this in  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  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  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
 or 
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  and the author of . 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 ,  and .

Check out my new course, .

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 .

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 .

Originally published at  on July 31, 2019.

바카라사이트 바카라사이트 온라인바카라