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.

Stumbled across this today

AWS has just announced SnapStart which starts your app after deployment, takes a snapshot of the disk + memory at that time, and then spawns very quickly an already initialized application.

This looks like a good solution to the BEAM slow start time shortcomings aforementioned in this topic.

Do you think we can leverage this with Elixir?