Rust web server vs lambda

I'm planning to create REST API for some project of mine, something people would typically do with Actix or Axum. I've recently come across the Serverless Application Model (SAM) of AWS, that uses Lambda functions as request handlers. I'm not as much aware of Lambda's execution model. But I wonder if, Lambda will provide the same level of resource efficiency as Axum/Acitx. By resource efficiency what I mean is, that Actix can spawn an async task (green thread) for each request and still run multiple tasks in the same thread on a single core concurrently. Is Lambda capable of providing that level of concurrency.

Some refs that I found:

I feel like you are trying to compare two different things here. Lambda is not a web server. It is a hosting service that happens to be serverless. You can run an axum web server as a Lambda function and it will work like it would when hosted somewhere else, as long as you stick to the event-based programming model of serverless functions. I.e. using the runtime to trigger some background task that will continue running after you returned a http response may not do what you want. Other than that, I can't think of any other restrictions to what you can and can't do compared to hosting your Rust web server in a more traditional/non-serverless hosting environment. You can even create streaming http responses.


So, basically running the axum web server using given lambda code example is the same as running axum web server on a dedicated ec2 instance, except for lambda will scale up automatically (i.e. allocate more resources) in times of high demand (i.e. too many requests), and scale down automatically as well, when there ain't as many requests to serve.
Confirm or correct me. Thanks for the response!

I don't think Lambda's execution environment can be compared to EC2 directly. I expect it to be leaner and more volatile when it comes to system resources and permissions. It is designed to be spun up and shut down often, so you can't persist anything within the environment. Which is all contrary to an EC2 instance which is a fully functional virtual machine, allowing you to write a stateful web server. You can't do stateful stuff within[1] your web server, if you host it as a function.

You are right that Lambda has scaling capabilities. But be mindful that Lambda scales by spawning more instances of your function (your web server)—all within their own execution environment—and not by beefing up one instance of your web server (i.e. gives it more memory and cpu quotas) that handles every concurrent request.

  1. Of course you can use other stateful services in your function, but you can't store state persistently in your execution environment. ↩︎

Then how is using this axum web server here any better than, using a simple request-response handler lambda function and attaching it to API Gateway? I guess it's not. So, in case of web servers having something like an EC2 would be more sensible than the Lambda architecture, right?
I guess you're very well able to understand where I am getting confused. So, if you have any pointers to resources that could clear things up for me, it would be much appreciated.

I'd say it is convenience, but I don't know the lamda_http API. Axum has a lot of nice abstractions and a big ecosystem that makes building HTTP servers very easy. On the other hand, using the Lambda API directly instead of a web framework is considered good practice for bigger serverless apps.

I'd say that depends on your concrete use-case and how complex you expect your backend will become. I think the decision between serverless or traditional hosting is mostly one of convenience vs. flexibility (besides vendor-lock and pricing, but these may be out of your hand). If you are building a simple RESTful API service on top of DynamoDB or RDS, don't see why you shouldn't use serverless (if you are dedicated to giving a lot of money to AWS, that is :smile:). But with everything that is as highly abstracted as Lambda's computing model is, you may find yourself confronted with a feature request that doesn't fit that well into the serverless model.

By the way, I think there's a middle ground between EC2 and Lambda you might wish to consider, EKS. Kubernetes gives you ridiculous configuration and scaling capabilities while still being as flexible as to allow you to self-host everything you might need for a modern web service in your cluster.

1 Like

The selling point of Amazon lambdas is that you only pay for the computing time. For example, if you launch a SaaS only in a certain region, it's perfectly possible that you won't have any users during certain hours; or if you're just launching the service, with EC2 it would be expected that your server isn't busy all the time processing requests.

1 Like

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.