Serverless-application-model: Accept a FunctionName parameter for AWS::Serverless::Function

[sapessi]

I'd like to be able to specify my own function name. In my template I receive the stage name as a parameter and I'd like to generate a function name such as "myfunction_${Stage}" -> "myfunction_dev".

This will make it easier for the on-call to find the function/logs that's causing the errors.

[gmetzker]

Agreed. This is quite important.

[gmetzker]

@sanathkr Any ETA on this feature? Seems like it would be nice to at least have parity with CloudFormation.

[sanathkr]

No ETA yet. This functionality, if done wrong, breaks your ability to deploy copies of the same stack to same region. We should think through this feature.

Would it be acceptable if SAM automatically appended your stack name with the Lambda function name? This way you are less likely to have two Lambda functions in the same region with same name.

[gmetzker]

I don't think SAM should be altering the name in anyway.

You should leave it up to the developer to decide on the name in the same way you can with CF. If there are name collision issues they can be handled in the same way as CF with a Stack Generation error.

Ultimately the developer should be able to choose any format that makes it unique. SAM should not be handholding.

In my case I want something like the following but another group might want something entirely different:

Resources:
  MySimpleFunction:
    Type: AWS::Serverless::Function
    Properties:
        Function:  !Sub 'my-simple-function-${stage}'

[lafiosca]

One potential use case for this feature: when you are using Lambda versioning and want to have a beta deploy and prod deploy in the same CodePipeline updating the same Lambda function. The CodePipeline flow goes something like this:

1. Source: git master merge triggers pipeline
2. CodeBuild: builds Lambda package zip, runs aws cloudformation package, and hands off output template and beta/prod config files
3. CloudFormation: creates and executes beta changeset, which replaces the $LATEST for the named function, publishes a version, and updates the alias beta to point to that version
4. Manual Approval
5. CloudFormation: created and executes prod changeset, which updates the alias prod to point to the version being pointed to by beta

We could accomplish this by having two totally separate Lambda functions published in different stacks, but then we're not technically cutting over to the deployed function version that has been tested and approved.

[lafiosca]

Although in retrospect I suppose that configuration could work even with the auto-generated name, operating on a single stack. I'll give it a shot.

[lafiosca]

After testing, I think either of the approaches mentioned by @sanathkr or @gmetzker would be fine for this use case.

[lafiosca]

Apologies for the verbosity... Further experimentation led me to discover what @sanathkr described in #41: that new versions don't publish each time. Guess I'll have to find a workaround for this either way.

[gmetzker]

In the AWS cloudformation forums I just saw this post:

AWS Lambda: Use the <code class="code">FunctionName</code> property of AWS::Lambda::Function 
resource to specify a name of your AWS Lambda function. 
Also, you can use Python 2.7 to specify an inline function.

Does this mean we can use this in SAM as well? Or will this be supported shortly?

[sanathkr]

We will support FunctionName in SAM shortly. I doubt we will try to do inline code. It just doesn't scale well.

[sanathkr]

FunctionName is here! - https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md#awsserverlessfunction