Wow, that’s pretty big news for people into serverless. I’m glad to have Elixir/Erlang supported there even though I personally probably won’t use it. It’ll definitely be interesting to see how they develop it.

It is a little concerning that AlertLogic consistently misspells Elixer in their announcement.

You should hear the people from my country almost always pronouncing and writing it as “Elexir”…

Stumbled across this today

I got the example working (GitHub - aws-samples/aws-lambda-elixir-runtime: Example implementation of a custom runtime for running Elixir on AWS Lambda. · GitHub). It was a bit of a hassle since I work on a Mac and then you cannot compile and build a release locally as it is a different platform than what Lambda runs on. So, I had to build the release within a Docker container, extract the build artifact and upload that to Lambda.

Just noticed GitHub - alertlogic/erllambda_elixir_example · GitHub does the same.

How were response times?

Did you measure cold start, hot start etc?

I’ll try and get back to you on that. Maybe I’ll do a writeup somewhere.

I had to build the release within a Docker container

Nice! I think that’s pretty common. Most recently I had to do this with python and Pillow. I also watched Kelsey Hightower extract the binary from a container running Fortran and ran it on lambda, which was pretty cool. I’m glad to see elixir get recognized here.

Guys, what do you think could be a useful use-case for elixir in aws lambda?

For sure a great visibility for the language and the community .. but I honestly don’t see elixir apps to be a good fit for aws-lambda as disposable functions. I see erlang/elixir strong on other things like macros (elixir), concurrency model etc.. to run an app that needs to be fault-tolerant not to be run for 30seconds and thrown away..

The same use case for any other language in lambda. Honestly, I haven’t found a reason to use anything other than python because boto3 is awesome. I have mainly used it for one off tasks that I don’t feel like building into the main app. Recently I’ve used it to process SQS using amazon polly. The elixir app is just running a genserver listening to the queue for completed items. How that text gets synthesized the elixir code doesn’t need to know or care about. So decoupling is a good use case. Especially when your language of choice is lacking integrations.

Kelsey Hightower (Mr. Kubernetes) gave a talk called the Path to Serverless. It’s a really good talk and I think it covers the basics of why serverless is important. Despite what I feel like is an over analyzation of the technology, the fact is you don’t need to maintain a server to run some code. It’s that simple. Serverless has been around since you could upload php files to a server and it just runs. We have serverless file hosting (s3), serverless database hosting (RDS), serverless queues (SQS), etc. Lambda is just serverless compute. Some people take it to the extreme and run entire web applications, and that’s fine but I think it depends on the scale. For example, we run a lambda that gets triggered when a thumbnail object is not in s3. This lambda generates the thumbnail on the fly, saves it to s3 and returns the image. These requests typically occur in large burst, lambda makes this trivial to handle the load. I have yet to pay a penny for the compute time.

Another important aspect with lambda is it’s triggers. This allows your cloud infrastructure to respond to events. Not everything is a http request. The use cases will evolve as the tech matures. Elixir on lambda would be good for api endpoints and glue functions. It’s also very cheap. Technologies like lambda **cough** firebase **cough** give react/vue devs and easy to implement backends. There are a lot of front end apps that are most static but contain small forms such as newsletter signup. Having elixir be a documented option helps language adoption. Official recognition is huge. Getting elixir in early gives developers the opportunity to solve real problems with their preferred language and add more use cases.

to run an app that needs to be fault-tolerant not to be run for 30seconds and thrown away

Lambda doesn’t just throw itself away when the function is done. The same event can trigger the same running lambda many times. Lambda is also as fault-tolerant as it gets. The problems lambda solves is definitely inline with the problems elixir solves but they’re not mutually exclusive. I think that’s very good for elixir. Technology like lambda will only continue to evolve. Today we have options, you could put an ALB with path based routing in front of long running stateful elixir code and short lived stateless lambda code (elixir or not). Take advantage of all the tools.

It’s not for everything or everyone, but dismissing something because of perceived value is not always wise. One could argue they don’t see the point of running elixir on kubernetes. It’s not about replacement, it’s about adding a tool and utilizing the right tool for the problem.