6 ms·

Erllambda: Run Erlang and Elixir in AWS Lambda

64 points by codeadict 8y ago

regularfry 8y ago
I've been saying for a while that Lambda (and serverless in general) should just be a compilation target, not a Radically New Computing Concept(tm). This is another inch towards that.
- tirumaraiselvan 8y ago
  This.
- vazamb 8y ago
  I think it is already through libraries. At least for lambda in python you have libraries (Zappa for example) that allow you to write basic flask and Django apps and then deploy them to lambda. These apps can still be deployed the "old" way with no or minor modifications
skrebbel 8y ago
Does this run a separate Beam instance for every Function? If so, isnt that an enormous waste of Erlang? If not, how isolated are requests? Can I send messages between them? Should I?
- kenhwang 8y ago
  Maybe it shares a beam instance per AWS account. Definitely curious about the isolation level of lambda in general since the same comment also applies to the JVM.
  - dvcrn 8y ago
    This means AWS would keep a beam instance running for you the entire time? I doubt that
    - kenhwang 8y ago
      I assume it'll cold boot one up for you if you didn't already have on running on first request, keep it around for a while, and when it becomes idle for a while, shut it down. There's a lot of blog content out there to try to ping lambda enough so the instance stays around to avoid the cold boot issue.
      - ghayes 8y ago
        If only there were a feature of lambda where it stayed up all the time...
        diegoperini 8y ago
        EC2 ?
        jeffasinger 8y ago
        Never having a cold boot isn't quite the same as being able to set a minimum concurrency level, though both would be very valuable. At re:invent this year, someone on the Lambda team indicated that they were working on something in this space, but couldn't say exactly what, or give any real timeline.
- nasmorn 8y ago
  Could it not keep a naked beam and load your code once it knows that the request is for you? This it could keep a few spares around that are almost hot.
- dalailambda 8y ago
  Lambda will create a function instance to handle concurrent requests, i.e. if 100 requests happen at the same time there will be 100 function instances. It will then however keep them "alive" for a few minutes allowing it to reuse already running instances. Additionally, a function instance won't handle multiple requests at a time. Given this, using beam is a bit of a waste in terms of individual instance scalability. That being said however, you might be able to use shared actor pools (e.g. caches, etc.) across all your functions. I want to emphasise the might as rapidly adding and removing nodes from the beam cluster might not work well or at all. At the end of the day, the lambda model kind of supplants the actor model as your unit of messaging and concurrency, and so trying to mix the two isn't the best idea. If you want to use the beam on AWS I'd recommend sticking to ECS/Fargate/EKS. That being said, Elixir might be a nice match due to developer ergonomics, just don't expect to be able to drag and drop actor reliant features.
bsaul 8y ago
Every time i read this kind of news i wonder : is there any real point to use erlang if you’re not taking advantage of its concurrency model ? Since the lambda model means concurrency is completely managed by the platform, why would you code in this language ?
- mercer 8y ago
  I can't speak for Erlang, but I use Elixir and not primarily for the concurrency model. I just really like the language (and it's functional-but-accessible approach), relative speed (compared to Ruby), fault-tolerance, community. In particular the fault tolerance and process-based approach is just awesome. I regularly find myself writing code with just the 'happy path' (and only the obvious error handling), which just feels a ton nicer than the more defensive approach I generally take in other languages. The tooling around the language is also really nice.
  - macintux 8y ago
    I can’t speak for Elixir, but I love Erlang for exactly those reasons.
    - mercer 8y ago
      Ha, I do suppose all those count for Erlang too. I get the impression that syntax-wise it's very much a matter of taste, although for some Elixir's macros might make it preferable.
  - CleanShirt 8y ago
    You’re gonna lose some of those features also on Lambda. The speed is gonna be subject to the time to cold start the VM, the times for this are not great for the JVM or .net runtimes.
- codeadict 8y ago
  Erlang has way more advantages than its concurrency model but none of these can be used in a lambda I guess. It is just good to have diversity, many will disagree but you get used to love the Erlang syntax and being able to run it in AWS lambda is kind of nice to not change the stack.
thedoops 8y ago
Pattern matching is a good fit for lambda use cases.
- cthalupa 8y ago
  Yep! Single biggest reason I'm excited for this. Nearly 100% of the lambda functions I've written could make use of erlang/elixir style pattern matching.

64 points by codeadict 8y ago

I've been saying for a while that Lambda (and serverless in general) should just be a compilation target, not a Radically New Computing Concept(tm). This is another inch towards that.

tirumaraiselvan 8y ago
This.
vazamb 8y ago
I think it is already through libraries. At least for lambda in python you have libraries (Zappa for example) that allow you to write basic flask and Django apps and then deploy them to lambda. These apps can still be deployed the "old" way with no or minor modifications

skrebbel 8y ago

Does this run a separate Beam instance for every Function? If so, isnt that an enormous waste of Erlang? If not, how isolated are requests? Can I send messages between them? Should I?

kenhwang 8y ago
Maybe it shares a beam instance per AWS account. Definitely curious about the isolation level of lambda in general since the same comment also applies to the JVM.
- dvcrn 8y ago
  This means AWS would keep a beam instance running for you the entire time? I doubt that
  - kenhwang 8y ago
    I assume it'll cold boot one up for you if you didn't already have on running on first request, keep it around for a while, and when it becomes idle for a while, shut it down. There's a lot of blog content out there to try to ping lambda enough so the instance stays around to avoid the cold boot issue.
    - ghayes 8y ago
      If only there were a feature of lambda where it stayed up all the time...
      - diegoperini 8y ago
        EC2 ?
      - jeffasinger 8y ago
        Never having a cold boot isn't quite the same as being able to set a minimum concurrency level, though both would be very valuable. At re:invent this year, someone on the Lambda team indicated that they were working on something in this space, but couldn't say exactly what, or give any real timeline.
nasmorn 8y ago
Could it not keep a naked beam and load your code once it knows that the request is for you? This it could keep a few spares around that are almost hot.
dalailambda 8y ago
Lambda will create a function instance to handle concurrent requests, i.e. if 100 requests happen at the same time there will be 100 function instances. It will then however keep them "alive" for a few minutes allowing it to reuse already running instances. Additionally, a function instance won't handle multiple requests at a time. Given this, using beam is a bit of a waste in terms of individual instance scalability. That being said however, you might be able to use shared actor pools (e.g. caches, etc.) across all your functions. I want to emphasise the might as rapidly adding and removing nodes from the beam cluster might not work well or at all. At the end of the day, the lambda model kind of supplants the actor model as your unit of messaging and concurrency, and so trying to mix the two isn't the best idea. If you want to use the beam on AWS I'd recommend sticking to ECS/Fargate/EKS. That being said, Elixir might be a nice match due to developer ergonomics, just don't expect to be able to drag and drop actor reliant features.

bsaul 8y ago

Every time i read this kind of news i wonder : is there any real point to use erlang if you’re not taking advantage of its concurrency model ? Since the lambda model means concurrency is completely managed by the platform, why would you code in this language ?

mercer 8y ago
I can't speak for Erlang, but I use Elixir and not primarily for the concurrency model. I just really like the language (and it's functional-but-accessible approach), relative speed (compared to Ruby), fault-tolerance, community. In particular the fault tolerance and process-based approach is just awesome. I regularly find myself writing code with just the 'happy path' (and only the obvious error handling), which just feels a ton nicer than the more defensive approach I generally take in other languages. The tooling around the language is also really nice.
- macintux 8y ago
  I can’t speak for Elixir, but I love Erlang for exactly those reasons.
  - mercer 8y ago
    Ha, I do suppose all those count for Erlang too. I get the impression that syntax-wise it's very much a matter of taste, although for some Elixir's macros might make it preferable.
- CleanShirt 8y ago
  You’re gonna lose some of those features also on Lambda. The speed is gonna be subject to the time to cold start the VM, the times for this are not great for the JVM or .net runtimes.
codeadict 8y ago
Erlang has way more advantages than its concurrency model but none of these can be used in a lambda I guess. It is just good to have diversity, many will disagree but you get used to love the Erlang syntax and being able to run it in AWS lambda is kind of nice to not change the stack.

thedoops 8y ago

Pattern matching is a good fit for lambda use cases.

cthalupa 8y ago
Yep! Single biggest reason I'm excited for this. Nearly 100% of the lambda functions I've written could make use of erlang/elixir style pattern matching.