4 ms·

Where I previously worked we used Elixir as the backend for a early-stage social app. We only really encountered the lack-of-libraries issue a single time (we

Where I previously worked we used Elixir as the backend for a early-stage social app. We only really encountered the lack-of-libraries issue a single time (we needed a Neo4j driver that supported their hosting platform). But aside from that, Elixir was a great choice and served us well. When our app went semi-viral all we needed to do was increase our instance size in AWS, never really needed to worry about horizontal scaling thankfully. Our app also needed a lot of realtime messaging and updates, which was genuinely a breeze with Phoenix. I don’t think I could ever to back to trying to finagle a websocket API in Python.

hosh 3y ago
If anything, scaling Elixir apps favors vertical scaling. Horizontal scaling starts hitting the limits of dist erlang (since, unless you restrict the topolog, every node connects with every other node). It makes for an interesting time when deploying to Kubernetes. But we figured out how to increase the number of cores per erl node during peak daily traffic. I’m working for a Nodejs shop now. For all its use of async stuff, it simply does not scale as well as Elixir (not to mention the deep dysfunctions in the Nodejs ecosystem).
- dsiegel2275 3y ago
  If I recall the things I've read on this in the past, the horizontal scaling limitations of distributed Erlang are encountered around like 500 to 1,000 nodes? Which I have to imagine means the large, large majority of shops using Elixir and scaling horizontally will be just fine, as they are typically in the size of 2 - 10, or maybe 20 nodes.
  - hosh 3y ago
    There is a reason stuff like Partisan were conceived - https://arxiv.org/abs/1802.02652 https://arxiv.org/abs/1802.02652 If you do a lot of cross node talk with say, the Phoenix channels, then lowering the total number of nodes helps (n*(n-1) for a full mesh). And since the BEAM scheduler will try to use up all available cores by default, past a certain threshold of nodes, it makes more sense to use smaller numbers of nodes with more cores per node. When you also have say, an observaility agent taking up 1000 mcore, doubling the instance size makes a difference. In the last shop, we would idle at 4-cores, jump to 16-cores instance sizes for the morning rush, and go back to 8-cores for the late afternoon traffic. I had tried to horizontally scale it with 4-cores machines, but saw a lot more instability and performance issues. This is one of the advantages with using Elixir or Erlang. You simply don’t get this kind of operational characteristics with Ruby, Python, or Nodejs.

hosh 3y ago

If anything, scaling Elixir apps favors vertical scaling. Horizontal scaling starts hitting the limits of dist erlang (since, unless you restrict the topolog, every node connects with every other node). It makes for an interesting time when deploying to Kubernetes. But we figured out how to increase the number of cores per erl node during peak daily traffic. I’m working for a Nodejs shop now. For all its use of async stuff, it simply does not scale as well as Elixir (not to mention the deep dysfunctions in the Nodejs ecosystem).

dsiegel2275 3y ago
If I recall the things I've read on this in the past, the horizontal scaling limitations of distributed Erlang are encountered around like 500 to 1,000 nodes? Which I have to imagine means the large, large majority of shops using Elixir and scaling horizontally will be just fine, as they are typically in the size of 2 - 10, or maybe 20 nodes.
- hosh 3y ago
  There is a reason stuff like Partisan were conceived - https://arxiv.org/abs/1802.02652 https://arxiv.org/abs/1802.02652 If you do a lot of cross node talk with say, the Phoenix channels, then lowering the total number of nodes helps (n*(n-1) for a full mesh). And since the BEAM scheduler will try to use up all available cores by default, past a certain threshold of nodes, it makes more sense to use smaller numbers of nodes with more cores per node. When you also have say, an observaility agent taking up 1000 mcore, doubling the instance size makes a difference. In the last shop, we would idle at 4-cores, jump to 16-cores instance sizes for the morning rush, and go back to 8-cores for the late afternoon traffic. I had tried to horizontally scale it with 4-cores machines, but saw a lot more instability and performance issues. This is one of the advantages with using Elixir or Erlang. You simply don’t get this kind of operational characteristics with Ruby, Python, or Nodejs.