fireproofsocks
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.
Most Liked
StorageCluster
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
Sebb
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.
dergraf
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.
Last Post!
bmalum
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
Trending in Discussions
Other Trending Topics
Chat & Discussions>Discussions
Latest on Elixir Forum
Sponsor Spotlight
Supporting innovation across the BEAM ecosystem.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #elixirconf-us
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Error tracking, logs, uptime, and Just Enough APM. Built for developers.
Practical resources that improve the lives of professional developers.
Develop your skills with books, videos, and courses.
Enabling companies to succeed by building software people love.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"