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

I’m not a Lambda fan-boy because I think it’s overprescribed as a cure-all for every possible problem when in reality, Lambdas are best suited for a narrower scope of tasks. Generally I wouldn’t think any VM-centric language would be a good fit for a Lambda because they would have a larger footprint and may take longer to start, but Java has been one of the Lambda options for a long time. So… clearly there’s more to the story.

Anyhow, because Lambdas often get brought up any time there’s a conversation about “serverless” deployments, I think they are a worthy topic of discussion.

There’s an old thread about Elixir on AWS Lambda: Elixir on AWS Lambda is coming soon

but I haven’t seen much on it recently. There’s even the aws_lambda_elixir_runtime Hex package, but it hasn’t been updated in quite a while (e.g. it uses Distillery instead of releases).

Ironically, I have had to think a lot MORE about the infrastructure when I use tools like serverless. However, one can’t ignore the push towards deploying apps in the context of various cloud services, so IaC tools are hard to ignore. I’m curious what people are thinking or have seen with respect to Elixir deployments and Elixir as a service. It would be nice to have easier deployments. Gigalixir is a great platform-as-a-service, but I’m wondering if there’s room for more tooling something that might a bit more like serverless or chalice that deals with automating the painful AWS permissions around getting something deployed.

1 Like

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.

1 Like

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 :wink:

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. :weary:

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.