Can a Lambda container host more than one function at once?
Is it possible for multiple Lambda function definitions to be deployed to the same container instance?
I understand that a given Lambda container will only execute at most one function at a time, but wanted to understand the composition relationship between functions and the host container.
For example, in the Serverless App project type for Visual Studio with the AWS Toolkit Extensions, it's possible to define multiple functions in a single project, but do these get deployed via CloudFormation into separate containers or a single container representing the project?
amazon-web-services aws-lambda
add a comment |
Is it possible for multiple Lambda function definitions to be deployed to the same container instance?
I understand that a given Lambda container will only execute at most one function at a time, but wanted to understand the composition relationship between functions and the host container.
For example, in the Serverless App project type for Visual Studio with the AWS Toolkit Extensions, it's possible to define multiple functions in a single project, but do these get deployed via CloudFormation into separate containers or a single container representing the project?
amazon-web-services aws-lambda
add a comment |
Is it possible for multiple Lambda function definitions to be deployed to the same container instance?
I understand that a given Lambda container will only execute at most one function at a time, but wanted to understand the composition relationship between functions and the host container.
For example, in the Serverless App project type for Visual Studio with the AWS Toolkit Extensions, it's possible to define multiple functions in a single project, but do these get deployed via CloudFormation into separate containers or a single container representing the project?
amazon-web-services aws-lambda
Is it possible for multiple Lambda function definitions to be deployed to the same container instance?
I understand that a given Lambda container will only execute at most one function at a time, but wanted to understand the composition relationship between functions and the host container.
For example, in the Serverless App project type for Visual Studio with the AWS Toolkit Extensions, it's possible to define multiple functions in a single project, but do these get deployed via CloudFormation into separate containers or a single container representing the project?
amazon-web-services aws-lambda
amazon-web-services aws-lambda
asked Nov 14 '18 at 13:04
SamSam
5,0002229
5,0002229
add a comment |
add a comment |
4 Answers
4
active
oldest
votes
I think it might help to separate out the process:
- A lambda deployment is a zip file of code, and a matching configuration. In the case of your Serverless App project type, when you have multiple lambda functions to a project, you're creating multiple deployments.
- A lambda instance is a running version of a deployment hosted inside of a container. Only one lambda instance is allowed in a container, that is an AWS guarantee. This means that you can never get access to code/memory/files outside of the currently running instance (either yours or anyone else's!)
As an optimisation AWS does re-use instances by freezing and thawing the container. This is because it's expensive to start a fresh container, copy the deployment, and do the init code of the deployment (known as the cold start).
Can you have multiple handlers per deployment? I need to understand if different handlers can be hosted together and re-use the same execution context, eg static initialization / in-memory cache, such as an API Gateway mapped to independent Lambda function handlers for different endpoints mapped through the gateway instance.
– Sam
Nov 14 '18 at 13:26
1
You can have whatever code you want in a deployment, but only the handler you configured to be so will get called. So you can share compile-time information between handlers (e.g. a file of constants, or common functionality), but you cannot share runtime information (e.g. connection pools, or variables set on init). (n.b. runtime information is shared by the container- not the instance, so two concurrent instances of the same handler will be running in separate containers).
– thomasmichaelwallace
Nov 14 '18 at 13:33
1
Each individual function in your project is stateless and self-contained.
– Arieh Kovler
Nov 14 '18 at 13:33
add a comment |
There's not an official document on the matter, but I will share what I have gathered the past years from Docs/Posts/Conferences:
Lambda functions are "framework" (or something like it, just that word is the closest I can think of and the only one I have heard from AWS representative) on top of a Containerization service. Every time you call lambda function a container is being run (it could be an existing one, put on hold - adds performance boost, or an entirely new one, you can never know which one it is.)
You could assume, the container instance (using instance as it is used in ECS, a host machine) is the same, having in mind there are some workarounds for DB Connection pooling and things of the like, but nobody guarantees you that.
add a comment |
CloudFormation will deploy the functions to the same AWS account. This is happening at the AWS user account level. It's not running the functions.
Lambdas are event-driven and only run when they are triggered. Every instance of a Lambda is standalone as far as the user experiences it, and is "deployed in its own container" when triggered.
Maybe something deeper is happening under the abstraction layers but that's how you'll experience it.
add a comment |
I did this by using ExpressJS+NodeJS. Every function is a different ExpressJS route. However, so far I have not been able to do it with Spring Cloud Function.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53300917%2fcan-a-lambda-container-host-more-than-one-function-at-once%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
I think it might help to separate out the process:
- A lambda deployment is a zip file of code, and a matching configuration. In the case of your Serverless App project type, when you have multiple lambda functions to a project, you're creating multiple deployments.
- A lambda instance is a running version of a deployment hosted inside of a container. Only one lambda instance is allowed in a container, that is an AWS guarantee. This means that you can never get access to code/memory/files outside of the currently running instance (either yours or anyone else's!)
As an optimisation AWS does re-use instances by freezing and thawing the container. This is because it's expensive to start a fresh container, copy the deployment, and do the init code of the deployment (known as the cold start).
Can you have multiple handlers per deployment? I need to understand if different handlers can be hosted together and re-use the same execution context, eg static initialization / in-memory cache, such as an API Gateway mapped to independent Lambda function handlers for different endpoints mapped through the gateway instance.
– Sam
Nov 14 '18 at 13:26
1
You can have whatever code you want in a deployment, but only the handler you configured to be so will get called. So you can share compile-time information between handlers (e.g. a file of constants, or common functionality), but you cannot share runtime information (e.g. connection pools, or variables set on init). (n.b. runtime information is shared by the container- not the instance, so two concurrent instances of the same handler will be running in separate containers).
– thomasmichaelwallace
Nov 14 '18 at 13:33
1
Each individual function in your project is stateless and self-contained.
– Arieh Kovler
Nov 14 '18 at 13:33
add a comment |
I think it might help to separate out the process:
- A lambda deployment is a zip file of code, and a matching configuration. In the case of your Serverless App project type, when you have multiple lambda functions to a project, you're creating multiple deployments.
- A lambda instance is a running version of a deployment hosted inside of a container. Only one lambda instance is allowed in a container, that is an AWS guarantee. This means that you can never get access to code/memory/files outside of the currently running instance (either yours or anyone else's!)
As an optimisation AWS does re-use instances by freezing and thawing the container. This is because it's expensive to start a fresh container, copy the deployment, and do the init code of the deployment (known as the cold start).
Can you have multiple handlers per deployment? I need to understand if different handlers can be hosted together and re-use the same execution context, eg static initialization / in-memory cache, such as an API Gateway mapped to independent Lambda function handlers for different endpoints mapped through the gateway instance.
– Sam
Nov 14 '18 at 13:26
1
You can have whatever code you want in a deployment, but only the handler you configured to be so will get called. So you can share compile-time information between handlers (e.g. a file of constants, or common functionality), but you cannot share runtime information (e.g. connection pools, or variables set on init). (n.b. runtime information is shared by the container- not the instance, so two concurrent instances of the same handler will be running in separate containers).
– thomasmichaelwallace
Nov 14 '18 at 13:33
1
Each individual function in your project is stateless and self-contained.
– Arieh Kovler
Nov 14 '18 at 13:33
add a comment |
I think it might help to separate out the process:
- A lambda deployment is a zip file of code, and a matching configuration. In the case of your Serverless App project type, when you have multiple lambda functions to a project, you're creating multiple deployments.
- A lambda instance is a running version of a deployment hosted inside of a container. Only one lambda instance is allowed in a container, that is an AWS guarantee. This means that you can never get access to code/memory/files outside of the currently running instance (either yours or anyone else's!)
As an optimisation AWS does re-use instances by freezing and thawing the container. This is because it's expensive to start a fresh container, copy the deployment, and do the init code of the deployment (known as the cold start).
I think it might help to separate out the process:
- A lambda deployment is a zip file of code, and a matching configuration. In the case of your Serverless App project type, when you have multiple lambda functions to a project, you're creating multiple deployments.
- A lambda instance is a running version of a deployment hosted inside of a container. Only one lambda instance is allowed in a container, that is an AWS guarantee. This means that you can never get access to code/memory/files outside of the currently running instance (either yours or anyone else's!)
As an optimisation AWS does re-use instances by freezing and thawing the container. This is because it's expensive to start a fresh container, copy the deployment, and do the init code of the deployment (known as the cold start).
answered Nov 14 '18 at 13:21
thomasmichaelwallacethomasmichaelwallace
2,5951917
2,5951917
Can you have multiple handlers per deployment? I need to understand if different handlers can be hosted together and re-use the same execution context, eg static initialization / in-memory cache, such as an API Gateway mapped to independent Lambda function handlers for different endpoints mapped through the gateway instance.
– Sam
Nov 14 '18 at 13:26
1
You can have whatever code you want in a deployment, but only the handler you configured to be so will get called. So you can share compile-time information between handlers (e.g. a file of constants, or common functionality), but you cannot share runtime information (e.g. connection pools, or variables set on init). (n.b. runtime information is shared by the container- not the instance, so two concurrent instances of the same handler will be running in separate containers).
– thomasmichaelwallace
Nov 14 '18 at 13:33
1
Each individual function in your project is stateless and self-contained.
– Arieh Kovler
Nov 14 '18 at 13:33
add a comment |
Can you have multiple handlers per deployment? I need to understand if different handlers can be hosted together and re-use the same execution context, eg static initialization / in-memory cache, such as an API Gateway mapped to independent Lambda function handlers for different endpoints mapped through the gateway instance.
– Sam
Nov 14 '18 at 13:26
1
You can have whatever code you want in a deployment, but only the handler you configured to be so will get called. So you can share compile-time information between handlers (e.g. a file of constants, or common functionality), but you cannot share runtime information (e.g. connection pools, or variables set on init). (n.b. runtime information is shared by the container- not the instance, so two concurrent instances of the same handler will be running in separate containers).
– thomasmichaelwallace
Nov 14 '18 at 13:33
1
Each individual function in your project is stateless and self-contained.
– Arieh Kovler
Nov 14 '18 at 13:33
Can you have multiple handlers per deployment? I need to understand if different handlers can be hosted together and re-use the same execution context, eg static initialization / in-memory cache, such as an API Gateway mapped to independent Lambda function handlers for different endpoints mapped through the gateway instance.
– Sam
Nov 14 '18 at 13:26
Can you have multiple handlers per deployment? I need to understand if different handlers can be hosted together and re-use the same execution context, eg static initialization / in-memory cache, such as an API Gateway mapped to independent Lambda function handlers for different endpoints mapped through the gateway instance.
– Sam
Nov 14 '18 at 13:26
1
1
You can have whatever code you want in a deployment, but only the handler you configured to be so will get called. So you can share compile-time information between handlers (e.g. a file of constants, or common functionality), but you cannot share runtime information (e.g. connection pools, or variables set on init). (n.b. runtime information is shared by the container- not the instance, so two concurrent instances of the same handler will be running in separate containers).
– thomasmichaelwallace
Nov 14 '18 at 13:33
You can have whatever code you want in a deployment, but only the handler you configured to be so will get called. So you can share compile-time information between handlers (e.g. a file of constants, or common functionality), but you cannot share runtime information (e.g. connection pools, or variables set on init). (n.b. runtime information is shared by the container- not the instance, so two concurrent instances of the same handler will be running in separate containers).
– thomasmichaelwallace
Nov 14 '18 at 13:33
1
1
Each individual function in your project is stateless and self-contained.
– Arieh Kovler
Nov 14 '18 at 13:33
Each individual function in your project is stateless and self-contained.
– Arieh Kovler
Nov 14 '18 at 13:33
add a comment |
There's not an official document on the matter, but I will share what I have gathered the past years from Docs/Posts/Conferences:
Lambda functions are "framework" (or something like it, just that word is the closest I can think of and the only one I have heard from AWS representative) on top of a Containerization service. Every time you call lambda function a container is being run (it could be an existing one, put on hold - adds performance boost, or an entirely new one, you can never know which one it is.)
You could assume, the container instance (using instance as it is used in ECS, a host machine) is the same, having in mind there are some workarounds for DB Connection pooling and things of the like, but nobody guarantees you that.
add a comment |
There's not an official document on the matter, but I will share what I have gathered the past years from Docs/Posts/Conferences:
Lambda functions are "framework" (or something like it, just that word is the closest I can think of and the only one I have heard from AWS representative) on top of a Containerization service. Every time you call lambda function a container is being run (it could be an existing one, put on hold - adds performance boost, or an entirely new one, you can never know which one it is.)
You could assume, the container instance (using instance as it is used in ECS, a host machine) is the same, having in mind there are some workarounds for DB Connection pooling and things of the like, but nobody guarantees you that.
add a comment |
There's not an official document on the matter, but I will share what I have gathered the past years from Docs/Posts/Conferences:
Lambda functions are "framework" (or something like it, just that word is the closest I can think of and the only one I have heard from AWS representative) on top of a Containerization service. Every time you call lambda function a container is being run (it could be an existing one, put on hold - adds performance boost, or an entirely new one, you can never know which one it is.)
You could assume, the container instance (using instance as it is used in ECS, a host machine) is the same, having in mind there are some workarounds for DB Connection pooling and things of the like, but nobody guarantees you that.
There's not an official document on the matter, but I will share what I have gathered the past years from Docs/Posts/Conferences:
Lambda functions are "framework" (or something like it, just that word is the closest I can think of and the only one I have heard from AWS representative) on top of a Containerization service. Every time you call lambda function a container is being run (it could be an existing one, put on hold - adds performance boost, or an entirely new one, you can never know which one it is.)
You could assume, the container instance (using instance as it is used in ECS, a host machine) is the same, having in mind there are some workarounds for DB Connection pooling and things of the like, but nobody guarantees you that.
answered Nov 14 '18 at 13:25
AlexKAlexK
844413
844413
add a comment |
add a comment |
CloudFormation will deploy the functions to the same AWS account. This is happening at the AWS user account level. It's not running the functions.
Lambdas are event-driven and only run when they are triggered. Every instance of a Lambda is standalone as far as the user experiences it, and is "deployed in its own container" when triggered.
Maybe something deeper is happening under the abstraction layers but that's how you'll experience it.
add a comment |
CloudFormation will deploy the functions to the same AWS account. This is happening at the AWS user account level. It's not running the functions.
Lambdas are event-driven and only run when they are triggered. Every instance of a Lambda is standalone as far as the user experiences it, and is "deployed in its own container" when triggered.
Maybe something deeper is happening under the abstraction layers but that's how you'll experience it.
add a comment |
CloudFormation will deploy the functions to the same AWS account. This is happening at the AWS user account level. It's not running the functions.
Lambdas are event-driven and only run when they are triggered. Every instance of a Lambda is standalone as far as the user experiences it, and is "deployed in its own container" when triggered.
Maybe something deeper is happening under the abstraction layers but that's how you'll experience it.
CloudFormation will deploy the functions to the same AWS account. This is happening at the AWS user account level. It's not running the functions.
Lambdas are event-driven and only run when they are triggered. Every instance of a Lambda is standalone as far as the user experiences it, and is "deployed in its own container" when triggered.
Maybe something deeper is happening under the abstraction layers but that's how you'll experience it.
answered Nov 14 '18 at 13:26
Arieh KovlerArieh Kovler
594
594
add a comment |
add a comment |
I did this by using ExpressJS+NodeJS. Every function is a different ExpressJS route. However, so far I have not been able to do it with Spring Cloud Function.
add a comment |
I did this by using ExpressJS+NodeJS. Every function is a different ExpressJS route. However, so far I have not been able to do it with Spring Cloud Function.
add a comment |
I did this by using ExpressJS+NodeJS. Every function is a different ExpressJS route. However, so far I have not been able to do it with Spring Cloud Function.
I did this by using ExpressJS+NodeJS. Every function is a different ExpressJS route. However, so far I have not been able to do it with Spring Cloud Function.
answered Dec 18 '18 at 11:49
pellyadolfopellyadolfo
426516
426516
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53300917%2fcan-a-lambda-container-host-more-than-one-function-at-once%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown