Streamlit on AWS: serverless options?
Question:
My goal is to deploy a Streamlit application to an AWS Serverless architecture. Streamlit does not appear to function properly without a Docker container, so the architecture would need to support containers.
From various tutorials, EC2 is the most popular deployment option for Streamlit, which I have no interest in pursuing due to the server management aspect.
AWS Lambda would be my preferred deployment option if viable. I see that Lambda can support containers, but I’m curious what the pros & cons of Lambda vs Fargate is for containerized apps.
My question is: Is Lambda or Fargate better for a serverless deployment of a Streamlit web app?
Answers:
AWS Lambda:
- AWS Lambda can run containers, but those containers have to implement
the Lambda runtime API. Lambda can’t run any generic container.
- Lambda has a maximum run time (for processing a single request) of 15 minutes. Behind API gateway that maximum time is reduced to 60 seconds.
- Lambda isn’t running 24/7. Your container would only be started up when a request comes in that the Lambda function needs to process.
- Given the nature of how Lambda works, something has to sit in front of Lambda to receive the web requests and route them to the AWS Lambda API. Most commonly this would be AWS API Gateway. So you would have to setup an AWS API Gateway deployment that understands how to route all of your apps API requests to your Lambda function(s). Alternatively you could put an Application Load Balancer in front of your Lambda function.
Fargate (or more appropriately titled "ECS services with Fargate deployments"):
-
Runs your container 24/7 like a more traditional web server.
-
Can run pretty much any container.
-
No time limit on the time to process a single request, although there is a maximum value of 4000 seconds (over 60 minutes) on the load balancer that you would typically use in this configuration.
So in general, it’s much easier to take a third-party app or docker image and get it running in ECS/Fargate than it is to get it running in Lambda.
My goal is to deploy a Streamlit application to an AWS Serverless architecture. Streamlit does not appear to function properly without a Docker container, so the architecture would need to support containers.
From various tutorials, EC2 is the most popular deployment option for Streamlit, which I have no interest in pursuing due to the server management aspect.
AWS Lambda would be my preferred deployment option if viable. I see that Lambda can support containers, but I’m curious what the pros & cons of Lambda vs Fargate is for containerized apps.
My question is: Is Lambda or Fargate better for a serverless deployment of a Streamlit web app?
AWS Lambda:
- AWS Lambda can run containers, but those containers have to implement
the Lambda runtime API. Lambda can’t run any generic container. - Lambda has a maximum run time (for processing a single request) of 15 minutes. Behind API gateway that maximum time is reduced to 60 seconds.
- Lambda isn’t running 24/7. Your container would only be started up when a request comes in that the Lambda function needs to process.
- Given the nature of how Lambda works, something has to sit in front of Lambda to receive the web requests and route them to the AWS Lambda API. Most commonly this would be AWS API Gateway. So you would have to setup an AWS API Gateway deployment that understands how to route all of your apps API requests to your Lambda function(s). Alternatively you could put an Application Load Balancer in front of your Lambda function.
Fargate (or more appropriately titled "ECS services with Fargate deployments"):
-
Runs your container 24/7 like a more traditional web server.
-
Can run pretty much any container.
-
No time limit on the time to process a single request, although there is a maximum value of
4000seconds (over 60 minutes) on the load balancer that you would typically use in this configuration.
So in general, it’s much easier to take a third-party app or docker image and get it running in ECS/Fargate than it is to get it running in Lambda.