8 ms·
My favorite Erlang container
- rektide 4y agoI'd love to hear what a more lean-in approach might look like. Using something like Krustlet[1] to write an Erlang-specific kubelet would be a more work-with way to approach k8s that'd still allow for a wide variety of deploymemt models, including things like this use of a universal container that gets live updated. [1] https://docs.krustlet.dev/topics/providers/ https://docs.krustlet.dev/topics/providers/
- RcouF1uZ4gsC 4y agoSometimes I feel that in modern distributed systems, we are very slowly and haphazardly recreating Erlang running on a IBM mainframe. What if we could treat an entire datacenter as a unified whole, a la an IBM mainframe, and use an Erlang style actor system for cross-region communication/coordination?
- slondr 4y agoYou can do that today, with Erlang, with relatively little setup
- yellowapple 4y agoI'd go further and assert that we're very slowly and haphazardly recreating an ad hoc, informally-specified, bug-ridden, slow implementation of half of Multics.
- theptip 4y agoI have a vague feeling that this is fighting the framework… what is the usecase here? Do you often have very-long-lived websocket connections that need to be preserved over upgrades? The “k8s way” here is to have your pods quiesce on rollout (old pods marked “unready” and removed from the Service), so existing connections are not torn down, but new connections get sent to the up-level pods. Then when all connections have drained from the down-level pods you terminate them. This would break down if you need to have say 1-hour websockets, but aren’t willing to wait 1h+ to roll out a new release. Is this a common requirement? Interested to hear examples of cases where extremely long-lived connections are worth a lot of engineering pain to achieve.
- jhgg 4y agoAt Discord, we maintain long lived web-sockets, and need to be able to deploy our real-time elixir based services (which runs on the BEAM VM just like Erlang) without any disruption to user traffic. To do so, we've built an application specific process migration system (this is BEAM VM processes, not OS processes) that is able to essentially live migrate processes both between nodes and software versions, allowing us to essentially replace the engine of the train while it's running, and also be able to scale up and down our clusters as needed. We are able to roll out updates across a hundred million processes on our distributed system in half an hour with no disruption to service. These are for internal services. For external services, we built the concept of "session resumption" which allows us to sever the TCP connection, have it accepted by a new/different host, and have it continue as if the connection wasn't ever terminated.
- bmitc 4y agoDamn, that's cool. Does Discord have any blog posts talking about this?
- abrookewood 4y agoJust seconding this - would love to hear more about Discord's use of Elixir
- sIacker 4y agoWhat would be good use cases for this? It’s not entirely clear to me how this reduces engineering
- rramadass 4y agoAlso relevant : https://cloudi.org/ https://cloudi.org/