Elixir on AWS Lambda? Or more broadly: Elixir as a Service

The startup is only an issue if you have few requests and the lambda has to cold-start. You can keep the lambda “warm” to not have to cold-start.

But I would not use Elixir as a lambda. It seems a little hacky. But more important, lambdas are usually used as very specialized functions. You have to build a system around it. Elixir/OTP is very good at just that: building a system. You’d give that up and make everything more complicated than needed. Depends on the use case obviously.

Agreed. I guess I’d say the same thing about Lambdas used as a webserver with routes etc. I’d rather have a on-demand EC2 instance or something. I wonder if you could have a BEAM instance running and have ad-hoc modules hot-loaded into it as needed. That’s really getting out there though…

Not an answer, more of an experience report

I’ve played at some point with AWS Lambdas written in Elixir, first by using one of the mentioned libraries and second by rolling it on my own using just HTTPoison. It made me realize how simple the architecture actually is or can be (assuming the official Lambda stacks do more or less the same as I did).

But that was only an experiment. Today we live with a mixed codebase of Javascript and Python based Lambdas used as custom Authorizers in AWS API Gateway. All our Lambdas are deployed using Terraform aws_lambda_function module. To make this work with plain Terraform we must store the Lambda dependencies, e.g. JS node_modules folder, in the same directory as the actual Lambda code, all checked into Git.

Separating the Lambda code from Terraform could solve this issue, which would be possible with the other Lambda flavors; deployment packages on AWS S3 or container images on AWS ECR. In contrast to the simple zip based approach, one must introduce a whole new process to separately test, build, and deploy those artifacts (but that’s what we do for our Elixir apps anyways, right).

I think if a Lambda codebase gets bigger, their dependencies more complex, using a separate CI/CD process for Lambdas outside of IaC becomes inevitable. We’re not at this point yet, but once we are, I would definitely do another round of experimentation with Elixir based Lambdas.

lambda deployment is not fun. We use serverless, thats ok.

Hi @dergraf, if you can remember what you did, would you be able to elaborate on how you managed to get elixir running on AWS Lambda for even a basic Hello World response. I have been trying something similar but struggled to get something running that didnt seem extremely hacky.

Im not a super proficient Elixir programmer but I was trying to use escript, burrito, and distillery, however with my approach runs into errors such as the following when I test my function.

/var/task/erts-15.1.2/bin/epmd: /lib64/libc.so.6: version `GLIBC_2.38' not found (required by /var/task/erts-15.1.2/bin/epmd)
/var/task/erts-15.1.2/bin/beam.smp: /lib64/libgcc_s.so.1: version `GCC_12.0.0' not found (required by /var/task/erts-15.1.2/bin/beam.smp)

Im hesitant to just jam in more dependencies as it feels like the wrong approach and it looks like my zip folder for my lambda will be significantly larger than what I was able to do when I tried the same in Haskell.

Hi!

I was using a containerized lambda instead of the classic zip file, see Create a Lambda function using a container image - AWS Lambda. this requires the containerized application to poll the AWS Lambda runtime for requests to be run, this is done using a Lambda runtime client, several libraries exists for this, but honestly it’s (was) two separate HTTP requests that were very straightforward to implement.I think I’ve started with this library GitHub - aws-samples/aws-lambda-elixir-runtime: Example implementation of a custom runtime for running Elixir on AWS Lambda. · GitHub.

Best,

there has been an update on the Elixir “native” on AWS Lambda. There is a project by @bmalum called Mayfly - just discovered it on https://elixir-aws-lambda.dev works well - sadly no Hex Package yet but runs with Elixir 1.19.3

just tested it in production - cold start execution seems fine with Mayfly which was 1.2s for me compared to Java Lambda it is very good, to native Node v22 it is “slow” which is 315ms. Every “warm” execution was <2ms for “Hello Elixir” Sample, which is was even faster than the native Node 22 Lambda (same output) at 3ms. @bmalum if you are still active here - maybe can you add a benchmark to the website?

Got your mention notification, thanks for advertising it. The project will be published on Hex.pm in the future. Benchmarks are a great idea – if time permits, I plan to put together a small comparison to make the trade-offs more transparent.

Cold starts are definitely a topic, but in my tests with larger applications they were consistently below 2 seconds. If that is still an issue and you want to stay with Elixir on AWS Lambda, using provisioned concurrency (around $4.50/month for a single always-warm instance) effectively eliminates the cold start problem. For my use case, the cold start overhead is acceptable and does not impact the workload significantly