I should have mentioned it in the post, but shout out to @peregrine for coming up with the FLAME concept together. Also @josevalim helping work through the impl details, as always ❤️
🧵
🧵
1/ Sending a closure across nodes in BEAM has always had the caveat "the code must exactly match", so has typically been avoided. @peregrine & I realized well we have a docker image of the release which guarantees matching code. We can also prevent mismatched code from clustering
2/ We do this by naming the node hostname based on the docker img ref. You can also do this by rolling the erlang cookie on each release
If we now have guaranteed matching code, and clustering only to matching code, then spinning up a copy of the app and sending closures is nbd
If we now have guaranteed matching code, and clustering only to matching code, then spinning up a copy of the app and sending closures is nbd
The rest is just leaning on BEAM features for remote monitoring/linking/clustering and handling the pool. We literally had a proof-of-concept built in a couple days thanks to BEAM and fly infra. "It feels like cheating" recurring theme in Elixir continues, even after 10 years
• • •
Missing some Tweet in this thread? You can try to
force a refresh
