Component: Function

[austencollins]

This Component abstracts all FaaS services and creates a common interface (that allows for custom configuration).

Instead of the interface approach like previous Component implementations, this would simply leverage the tree approach we are using now. It would contain multiple SDKs and the knowledge of how to use them to deploy to different FaaS products.

[eahefnawy]

@ac360 do you think this is where we should add the layers functionality? rather than in the AwsLambda component?

[pmuens]

What's the value of having this vs. a raw Lambda / CF component?

The user usually knows in which cloud she wants to deploy the application.

I never saw the value of such a component in the old implementations. It was just another layer of abstraction which caused confusion and a bloated codebase (a reason could've been that the old implementation was quite involved).

[eahefnawy]

@pmuens I think it's useful to have a common interface between providers, with UFS...etc

[austencollins]

A few benefits, imo:

• This is where we bake in a permission management abstraction to simplify permissions for once and for all.

I have a vague idea for this that I'm dying to prototype...

A single line, vendor-agnostic, ARN-like concept that includes the resource, but also includes permissions. Something like this...

aws:[service]:[serviceInstance]:[permissions]

Examples:

aws:dynamodb:*:*
aws:dynamodb:users:read
aws:dynamodb:users:write
aws:dynamodb:users:crud
aws:dynamodb:myapp*:crud
aws:ddb:users:crud
aws:ddb:users:crud:useast1
google:vision:query
azure:functions:write

components:
  Function::createUser
    permissions: 
      - aws:ddb:users:write

• This would use the Code Component to separate code from the infrastructure resource in all ways (building vs. deploying, testing, etc.)

• Function

• Code

• AwsLambda

• An easier building block for other component authors to provision code for their component use-cases across clouds. (Though we'd just start w/ great lambda support).