(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.
(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.