Vercel's fluid compute

Yasar Arafath — Thu, 10 Jul 2025 18:17:04 GMT

The good

I’ve been a fan of serverless functions for a long time. In the early years, it was partly because of the fancy term “serverless” — it felt like magic, straight out of a fantasy. Ever since AWS Lambda launched in 2014, it has been a hot topic in the infrastructure world. It eliminates most of the infrastructure overhead: just write some code, package it, deploy it as a function, and it scales like magic. Sounds good, right?

The bad

Although serverless makes the most sense for stateless applications, it comes with some serious downsides — most notably, cold starts. While services like AWS Lambda have reduced cold start times significantly, it's still one of the drawbacks of serverless architecture. On top of that, CPU timings and wall-clock timings make cost predictions harder, adding another layer of complexity.

Fluid compute

Vercel’s new computing solution is called Fluid Compute, and I think it addresses some of the key problems we’ve had with traditional serverless architecture. While nothing has fundamentally changed, Fluid Compute allows the reuse of the same underlying hardware to run multiple functions. This greatly reduces costs, as multiple functions share the same resources.

Some sources suggest that Vercel still uses AWS Lambda under the hood, but they’ve engineered a sophisticated layer on top to achieve high levels of application concurrency. Since the same hardware is used to run multiple functions simultaneously, cold start times are also significantly reduced.

The thing I’m most excited about is application concurrency — it can significantly reduce application latency.

If you want to learn more about Fluid Compute, I highly recommend reading Original article from vercel.

If the sources are correct — and Vercel is indeed using AWS under the hood while still achieving this level of application concurrency — then I believe they could do an even better job if they owned the infrastructure themselves.

Let me know what do you think 😉.

Deploying python docker containers on aws lambda

Yasar Arafath — Sun, 02 Feb 2025 06:42:08 GMT

In this article, we are going to go through how to deploy your Python Docker containers to AWS Lambda.

Architecture of AWS Lambda

AWS Lambda architecture is slightly different from traditional server architecture. It runs functions as code, meaning you define your logic in a function of code and let Lambda take care of deploying and running your code.

So, let’s get started.

Code

In app.py:

import json

def lambda_handler(event, context):
    return {
        "statusCode": 200,
        "headers": {
            "Content-Type": "application/json"
        },
        "body": json.dumps({"message": "Hello from AWS Lambda!"})
    }

In Dockerfile:

FROM public.ecr.aws/lambda/python:3.11

COPY app.py /var/task/

CMD ["app.lambda_handler"]

Here, the Python base image must be pulled from AWS ECR. We have to log in to Docker with AWS ECR (assuming the reader has AWS account access):

aws ecr get-login-password --region  | docker login --username AWS --password-stdin .dkr.ecr..amazonaws.com

Replace your account ID and your region in this command, and you'll be good to go.

Now, tag the Docker image you just built with the repository name in AWS ECR:

docker tag :latest :latest

Now we can finally push our image to AWS ECR:

docker push :latest

Lambda

In the AWS Lambda management console, go ahead and create a new function.

Click on "Create function," choose the container image option, and select the ECR repository from the dropdown.

That’s it! Your function is now ready.

We can also check its functionality by clicking on the test button to make sure everything is working as expected.

Now that we have set up our Lambda function, we need to make the function available to the public internet. To do this, we are using AWS API Gateway.

Yasar's blog