Why isn't Elixir dominating serverless architecture?

Because “serverless” is a temporary fad on resurrecting CGI.

“Serverless” scripts should be able to start and stop quickly, as these are “run once” scripts. Elixir is very bad at such approach, it is better to have long-standing VM that accepts connections.

On the other hand within BEAM machine it is “serverless” as each incoming connection (at least in most of the HTTP servers out there) is new process, just like in serverless.

First time I hear it. Could you elaborate?

You mean cowboy with ranch? It actually uses a pool of GenServers that take requests. Or perhaps I am not understanding your point. Could you specify what you mean?

Thanks for dropping by!

I’ve not listened to the podcast, but I see two point in terms of elixir and serverless technology:

For orchestration: I guess it’s because of existing knowledge in other languages in teams building those systems. Also the beam doesn’t really have a straight forward story for executing user-code within the vm, so it’s going to need a technology mix anyways.

As the executed runtime: The beam is not the best vm to be started up for a single task and stopped right afterwards.

I guess the beam excels at “self hosted serverless”, when you can deploy your own trusted code to be run.

Aka serverless, but from 90s-00s. There was a reason why we stopped that, and IMHO there is no point in resurrecting that technology.

Ranch pool is number of acceptors not connections. Quote from docs:

First of all, it should not be confused with the maximum number of connections. Acceptor processes are only used for accepting and have nothing else in common with connection processes. Therefore there is nothing to be gained from setting this number too high, in fact it can slow everything else down.
– Ranch Internals docs

So while connection gets accepted by the Ranch, “connection handling” takes place in separate process AFAIK.

Maybe because Elixir doesn’t shine as bright when you take away the OTP, the clustering and long-running processes that pass messages between each other thanks to the BEAM VM?

Surely, it’s a nice enough language to be used to write functions with, and in fact very nice with the pattern matching and language constructs it has, also macros. But that maybe has not enough weight to take away the huge popularity of JavaScript and Python has and user base, while the end result is going to be pretty much the same.

Elixir & Erlang make sense when you are building distributed, long-running, message-passing system, which is the counter-definition of “serverless” architecture.

Simply put, because the current serverless hosting providers destroy the OS process after it has called one function (okay, most of the time; some of them keep the instance around for a bit) and because the BEAM isn’t starting up particularly quickly. It wasn’t designed to be started and stopped many times just to do one small task. It was designed to be a long-running service.

Contrast that to the average Go, Rust or OCaml compiled binary that starts up in 0.5 - 8.0 milliseconds.

Maybe I’m misunderstanding, but wasn’t Dave Thomas’ point to use Elixir as infrastructure for serverless? In other words, you would still write your small serverless functions in JS, Python, Go etc., but the system running them would be written in Elixir.

some links about serverless :

https://medium.com/coryodaniel/from-erverless-to-elixir-48752db4d7bc

I don’t believe BEAM is built with a level of sandboxing required to run untrusted code in mind. Whenever you have a “serverless” architecture, you are allowing programmers to send functions and execute them on a virtual machine somewhere in the cloud, along with other programmers doing the same. I don’t know how technically this is done, but I suspect a strong reliance of OS-level sandboxing and one-off virtual machines, possibly keeping a pool of them already started and allowing instant execution, and then discarding them after the execution. It’s an educated guess but you can probably get to the details here: https://d1.awsstatic.com/whitepapers/Overview-AWS-Lambda-Security.pdf

Now, you could replace all that with BEAM if beam was built to do so. But it’s not. There is a lot of ways to start processes, call functions on current or remote nodes, execute code dynamically. It’s just going to be a nightmare trying to secure that environment and allow execution of untrusted code that needs to be sandboxed. A nightmare to the point of “it ain’t going to happen”, I think.

Similar thread: How to create a sandbox to run untrusted code/modules? - #25 by OvermindDL1

As far as I’m concerned the concepts behind CGI continue to exists in the form of PHP which had and continues to have a good run.

Because “serverless” is a temporary fad on resurrecting CGI.

PHP managed to stick around for a long time.

https://medium.com/@keithwhor/rise-of-functions-as-a-service-how-php-set-the-serverless-stage-20-years-ago-ccb560c5f422

I don’t see serverless/FaaS being a temporary fad. It has its problems but the initial cost/maintenance model can look way too attractive even though it can really bite you later.

So Jeff will likely stick around for a while.