There is a following setup:
2 lambda functions, deployed using serverless.yml
custom domain (e.g. api.mydomain.com) attached to API Gateway
2 stages (dev and prod)
CNAME configuration in my domain to point to abcdefg.cloudfront.net
There's a high-level task to update two lambda functions without the downtime for the API that they are serving. How to do it using serverless framework?
Note: there are two ways to manage lambda deployments: stages and aliases (versions). Currently aliases do not work in serverless (there's a fork that hotfixes the issue, but it does not matter atm).
There is no downtime when updating a lambda function using the Serverless Framework, simply by running sls deploy.
The function code is zipped and uploaded to Lambda, and when that is completed, CloudFormation will update the Lambda configuration to point to the new code. There is no downtime in this process.
Related
I have an AWS Lambda "Application" which was created from an AWS Lambda app template. This in turn created two stacks. The serverlessrepo-??-toolchain stack and the Lambda Application stack that has the actual application...
I've done the development and added lambdas, permission, and such. Really evolved the template.yml and the buildspec.yml.
It all works and properly rebuilds the stack.
But in an AWS Lambda Application that is using CodeDeploy/CodePipeline, what is the best strategy for deploying additional environments? Let's assume the first one - the one made by the serverlessrepo-??-toolchain stack -- is Dev. How do I create a QA and Prod from my template.yml?
They need to be new stacks, yes? As in each environment is its own stack.
Thank you.
Need to deploy a serverless function in aws lambda using serverless. Serverless uses aws Cloud formation to build the stack completely and uploads the module into S3. It uploads by default into S3, but the intended file is less than 10 mb which could be attached in aws lambda directly. How to configure the serverless.yml to achieve the scenario.
This is not possible.
You've asked serverless to create a CloudFormation template that creates some lambdas. When AWS executes the template, it executes it in the cloud away from your computers local files. Thats why your code is packaged, uploaded to S3, and made available for CloudFormation use.
CloudFormation does allow for code to be inline in the template but serverless does not support this. And there is no way to ask CloudFormation to create a lambda without code attached for manual upload at a later date.
Frankly the cost to have the additional bucket and a few small files is minimal (if any). If the concern is the additional deployment bucket, you can specify a deployment bucket name for multiple serverless deployments.
I am new to Serverless and AWS SAM.
I have tried creating a template.yaml for my new lambda functions and api gateway's of my application and deployed to AWS using AWS SAM. It worked fine.
But my question is for every deploy, we got to create new cloud formation stack but is there a way we can update the individual lambda codes for a function without deploying whole stack using AWS SAM?
I did check Serverless framework as well in which we can use below command to individually deploy lambda function without creating new stack
serverless deploy function -f functionName
Is there any such flexibility using SAM ?I did check SAM CLI which provides local environment for testing the api's and lambda functions, but haven't seen any individual deploy function for lambda. Could someone help me out?
Recently I have been looking into AWS Lambdas and how to build Serverless API using .Net Core. From what I understand, you can do it in 2 different ways.
1) Write multiple separate Lambdas in C# and deploy them to AWS. Requests come in via API gateway and each lambda acts as an endpoint.
2) Build a Serverless Web API using .Net core. When you create the serverless Web API project a Lambda is automatically created which becomes the entry point to the Web API.
Are there any limitations of 1 vs 2, or use cases where one approach might be beneficial over other? Or is it just 2 different ways of achieving the same thing?
I don't think your options are correct. The two options for building a Lambda backed API are:
1- Build lambdas and deploy them independently to AWS in one or more project. Then Manually create API Gateway endpoints that point to your one or more lambdas.
2- Use a Serverless project to combine your lambdas in one project. Define your endpoints in that project and have Cloudformation create the API Gateway endpoints and hook them up to your lambdas on deployment.
As far as pros and cons,
Option 1:
Pros: has the flexibility of deploying lambdas independently, also you can configure your API Gateway endpoints however way you want without having to understand Cloudformation definition syntax which took some ramp up time in my experience.
Cons: If you have a lot of lambdas this becomes a management nightmare. Also your endpoint definition is not in the source code and changes to the endpoint configuration will not be tracked.
Option 2:
Pros: If you figure out Cloudformation or if you want to go with the default configuration deploying a lambda and hooking it to an API Gateway endpoint is super easy. AWS will create the endpoint for you and will create dev and prod stages, policies, IAM roles, etc. This being deployed by Cloudformation directly from Visual Studio causes the whole deployment and all related objects to fall under the same "Stack" in AWS Cloudformation which can be changed, repliocated, or deleted very easily. Also your Infrastructure is now code and changes to it are auditable in your git repo.
Cons: The biggest con in my opinion is the fact that the stack doesn't span the VS Solution but rather just the project, so all your lambdas have to live in the same project which means that if you have a lot they will end up all in one monolith lambda binary. The generated large project binary will costing you memory runtime on AWS and efficiency problems. The other con is that if you want to have specific or out of the ordinary API Gateway you will need to understand Cloudformation syntax to change your serverless.template file.
Conclusion: My preferred solution was to divide my true application into smaller chunks of related lambdas based on the API object and place these lambdas in a few Serverless application projects. For example I have an order project which contains all lambdas related to the order API, and a Product project that contains the lambdas related to product API etc. Both of them would live in the same solution and would get deployed separately. I'm currently working on a way to deploy the entire solution at once.
I want to migrate a huge Serverless project, created with the Serverless Framework, from v0.5 to v1 and my biggest concerns are that resources (DynamoDB tables) that were deployed in sls 0.5 version will be deleted or modified if I would try to deploy from sls version v1.
It is known fact that v1 is not compatible with 0.5... So is it possible to migrate 0.5 resources to 1.0 without breaking the cloud formation structure of DynamoDB tables in AWS? In another word: how to migrate 0.5 resources to 1.0 in a safely manner?
Edit: I have full AWS API gateway in front.
Important: Please try this on a non-production environment first.
Don't do an sls remove on the v0.5 project.
Rewrite your API Gateway and Lambda functions in serverless v1.x but don't include the DynamoDB resources. This means v1.x will only deploy API Gateway endpoints and AWS Lambda functions.
In your Lambda handlers, use the same DynamoDB tables as before.
I'd consider looking into blue green deployments. For DynamoDB you can utilize streams to ensure data is in sync. You mentioned server less but it's hard to recommend a solution there without knowing if you're just doing lambda or if you've got an API gateway in front. In those cases you might want to look into stage variables.