My favorite Erlang container

Sometimes I feel that in modern distributed systems, we are very slowly and haphazardly recreating Erlang running on a IBM mainframe.<p>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&#x2F;coordination?

I 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?<p>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?<p>Interested to hear examples of cases where extremely long-lived connections are worth a lot of engineering pain to achieve.

I&#x27;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&#x27;d still allow for a wide variety of deploymemt models, including things like this use of a universal container that gets live updated.<p>[1] <a href="https:&#x2F;&#x2F;docs.krustlet.dev&#x2F;topics&#x2F;providers&#x2F;" rel="nofollow">https:&#x2F;&#x2F;docs.krustlet.dev&#x2F;topics&#x2F;providers&#x2F;</a>

What would be good use cases for this? It’s not entirely clear to me how this reduces engineering

Also relevant : <a href="https:&#x2F;&#x2F;cloudi.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;cloudi.org&#x2F;</a>