Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How does this work!? Can't see Erlang being officially supported on AWS Lambda!? #1

Open
kristianmandrup opened this issue Jan 17, 2017 · 5 comments

Comments

@kristianmandrup
Copy link

Hi,
Thanks for the repo.
Been trying to figure out best way to host an Elixir/Phoenix app on AWS.
If I go to AWS lambda docs, they don't mention Erlang being supported yet, so...?? Maybe just not updated or a workaround?
Please explain in Readme or answer this issue. Thanks again.

@jschoch
Copy link
Owner

jschoch commented Jan 17, 2017

Thanks for the interest, take a look and if this answers your question i'll update the readme.

I wouldn't say this is the best way to run Elixir on AWS. There are many ways to do something that broad.

If you want to run Elixir on Lambda then this is the only lib I am aware of which does that. Be aware that Lambda may not suite your use case due to cold start times and it's statelessness.

Running arbitrary stuff is supported, it is just not 1st class yet. https://aws.amazon.com/blogs/compute/running-executables-in-aws-lambda/

The way this works is that it uses's node's module initialization to start up a server in the lambda instance. It then uses node.js to pass events via http to the server which can be processed by your code. This packages your elixir code up into a release. You can read up on that here: https://github.com/bitwalker/distillery

Also note that VPC makes cold starts worse: https://robertvojta.com/aws-journey-api-gateway-lambda-vpc-performance-452c6932093b#.q3k85e4ng

@kristianmandrup
Copy link
Author

Great thanks! Sounds like a better option would be to deploy directly on EC2 or perhaps use Xen?
Your thoughts? I mean since OTP already manages independent light weight processes why put Lambda in the mix?

@jschoch
Copy link
Owner

jschoch commented Jan 17, 2017

Ec2 or ECS would work for you.

OTP is great, but you often don't need OTP. Elixir's syntax and functional nature is enough for me to prefer it over python, javascript, or java.

Lambda is great for things that are not latency sensitive (like processing an email), but do need to be highly available. Running 10k lambda requests per month is much cheaper than standing up several servers to wait around for events. You can also trigger lambda functions from other Ec2 events such as a S3 PUT.

@tomasz-tomczyk
Copy link

@jschoch what kind of start up time are you experiencing when booting up a task? You mentioned here that you somehow start the Erlang VM in the initialization? Would you be able to elaborate on that or point me in a direction of how this is implemented?

@jschoch
Copy link
Owner

jschoch commented Jan 19, 2017

this isn't ideal but it works:

Essentially without this sleep the function will return the context and the container will become frozen (execution is paused). This leads to some odd behaviors such as only success on the 2nd or 3rd requests depending on the sum of un-frozen execution time.

Open to ideas on how to improve this hackish approach. It does produce good results assuming your lambda container isn't getting recycled all the time due to inactivity or your use case can't deal with some long starts.

The other big wart is the 777 permissions required. The lambda function is not exposed and assuming you are safely parsing input this seems like a low risk area, but I should point it out. The problem is that your lambda container gets created and deployed with a special user. After initialization events produce invocations executed by semi-random userid's and never by the user who owns the files.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants