I'm just starting to get into and understand serverless architecture. What's the use case for deploying an entire web application on AWS Lambda, rather than extracting the functionality into single purpose tasks, Dockerizing them, and deploying those as Lambdas? It's my understanding that the resources available on Lambda are pretty limited, so anything that requires a full web framework or database connection probably isn't a good use case for Lambda.
But like I said, I just started learning about serverless, so I'm still trying to wrap my brain around good vs. bad implementations. :)
What I've used Lambda + Flask + Zappa for is Amazon Alexa Skills. I used to have them written in NodeJS, but have been rewriting them all with Flask-Ask ( github.com/johnwheeler/flask-ask ) and deployed to Lambda.
Same question here. We have developped our own Framework (Services, DAO etc...) that is served by flask. Have you found a way to incorporate it into AWS Lambda?
(This question was left hanging. I hope it is still useful for someone.)
I haven’t deployed Python/Flask implementation with lambda, but I have done something similar with JavaScript Node/Express and C#/WebAPI. Basically they all use API Gateway with proxy integration where the entire request is sent to your lambda and it’s responsible for all of the request routing, response, security, etc.
The advantages are:
fewer cold starts. The traditional method of using one lambda per request, means that endpoint is mostly likely to see a delay if it hasn’t been hit recently.
familiar development work flow: locally you work with the same tools that you are use to.
portability. I created a REST API that allows us to save and retrieve documents to/from S3. I knew I was going to hit the 6MB lambda request limit and eventually I was going to have to move it from lambda. I was able to move it to Fargate (more below) without any code changes. We had no experience with a Fargate at the time and we had to get it done.
I wouldn’t do an “entire website” with it though. The usual pattern is to host your REST API in lambda, host your website in S3, and use a client side framework.
Now on to Docker. You’re mixing to concepts. Docker/Fargate is its own serviceless offering. It’s more expensive than lambda, but it has advantages of being able to run continuously with no coldstarts. No request/response limit. and more options for CPU/Memory.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'm just starting to get into and understand serverless architecture. What's the use case for deploying an entire web application on AWS Lambda, rather than extracting the functionality into single purpose tasks, Dockerizing them, and deploying those as Lambdas? It's my understanding that the resources available on Lambda are pretty limited, so anything that requires a full web framework or database connection probably isn't a good use case for Lambda.
But like I said, I just started learning about serverless, so I'm still trying to wrap my brain around good vs. bad implementations. :)
What I've used Lambda + Flask + Zappa for is Amazon Alexa Skills. I used to have them written in NodeJS, but have been rewriting them all with Flask-Ask ( github.com/johnwheeler/flask-ask ) and deployed to Lambda.
Same question here. We have developped our own Framework (Services, DAO etc...) that is served by flask. Have you found a way to incorporate it into AWS Lambda?
(This question was left hanging. I hope it is still useful for someone.)
I haven’t deployed Python/Flask implementation with lambda, but I have done something similar with JavaScript Node/Express and C#/WebAPI. Basically they all use API Gateway with proxy integration where the entire request is sent to your lambda and it’s responsible for all of the request routing, response, security, etc.
The advantages are:
fewer cold starts. The traditional method of using one lambda per request, means that endpoint is mostly likely to see a delay if it hasn’t been hit recently.
familiar development work flow: locally you work with the same tools that you are use to.
portability. I created a REST API that allows us to save and retrieve documents to/from S3. I knew I was going to hit the 6MB lambda request limit and eventually I was going to have to move it from lambda. I was able to move it to Fargate (more below) without any code changes. We had no experience with a Fargate at the time and we had to get it done.
I wouldn’t do an “entire website” with it though. The usual pattern is to host your REST API in lambda, host your website in S3, and use a client side framework.
Now on to Docker. You’re mixing to concepts. Docker/Fargate is its own serviceless offering. It’s more expensive than lambda, but it has advantages of being able to run continuously with no coldstarts. No request/response limit. and more options for CPU/Memory.