Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

Components

The deployment of code to AWS Lambda involves several major components as follows:

  • Functionthe custom code that processes events from an event source (see below) custom code in AWS Lambda is referred to as a Lambda function, which consists of code, associated dependencies, and configuration, see Lambda Function and Event Source
  • Layer – Lambda layers are a distribution mechanism for libraries, custom runtimes, and other function dependencies. Layers let you manage your in-development function code independently from the unchanging code and resources that it uses, see Lambda Layers
  • Event Sourcepublishes events that cause a Lambda function to be invoked, either by the event source in the "push" model, or by AWS Lambda in the "pull" model, see The Pull/Push Event Models

Workflow

The typical deployment workflow comprises one mandatory and two optional phases:

Create an AWS Lambda function

upload the application source code (the 'Deployment Package') – see the Upload File(s) action of the Amazon S3 Object task

create a function – see the Create Function action of the AWS Lambda Function task

(optional) invoke the function – see the Invoke Function action of the AWS Lambda Function task

Custom Bamboo task

This effectively comprises a custom Bamboo task, which allows you to implement arbitrary functionality running in AWS Lambda instead of a dedicated task.

(Optional) Create an AWS Lambda Event Source Mapping (pull event model)

(optional) create an appropriate event source via AWS CloudFormation, e.g. an Amazon Kinesis stream, an Amazon DynamoDB table, or an Amazon SQS queue – see the Create Stack action of the AWS CloudFormation Stack task

create an event source mapping – see the Create Event Source Mapping action of the AWS Lambda Event Source Mapping task

Disable until tested

Kinesis and DynamoDB streams can create a huge amount of events in a short time, so you might want to create an event source mapping in the Disabled state and update it to Enabled explicitly at a later stage once the deployment is properly tested.

(optional) update an event source mapping – see the Update Event Source Mapping action of the AWS Lambda Event Source Mapping task

the event source mapping can be adjusted at any time during its lifetime, for example to enable/disable it during maintenance

Illustration of the Lambda pull event model

(Optional) Add/Permit an AWS Lambda Event Source (push event model)

Illustration of the Lambda push event model

Illustration of the Lambda push event model

Alternative workflow via CloudFormation

A typical workflow based on CloudFormation might look as follows:

  1. upload the application source code (the 'Deployment Package') – see the Upload File(s) action of the Amazon S3 Object task

Frequently Asked Questions (FAQ)

Atlassian account required

Due to a regression within Questions for Confluence Cloud, you need to log in with your Atlassian ID (or sign up for a new account) to access these automatically curated FAQs (refer to UAA-312 for the background).

  • No labels