3 ms·
As a developer who uses go microservice architecture and is in the process of containerizing our services at work, this is very valuable. Thank you! As an elix
by chessturk 7y ago
As a developer who uses go microservice architecture and is in the process of containerizing our services at work, this is very valuable. Thank you!
As an elixir/erlang enthusiast, haven't we just reinvented BEAM and observer?
- pdimitar 7y agoYep. No small amount of Erlang/Elixir programmers are kind of amused how K8s is trying to invent OTP for nodes.
- mercer 7y agoI wish we could somehow convince the undoubtedly very smart people working on K8s to just get on the BEAM and go from there? You know, work on Dialyzer, fix my code highlighting issues in VSCode, make Elixir faster, somehow make it easy to create cross-platform binaries, and give me a platform-native Observer ;).
- pdimitar 7y agoI suppose it's not easy to part with the illusion that containers should not be ephemeral. I mean, that's probably easy to do for microservices; you fire off a function, it does something useful and returns back quickly. Having K8s do a home-grown lambda hosting for you is useful there. But the moment you introduce any state, the whole idea of ephemeral containers is much more of a hindrance than something actually useful. A singular BEAM VM might run (realistically) tens of thousands of processes that do a lot of useful work. It's just not practical to kill off such a container and hand-wave away the huge costs of spinning it back up. IMO K8s and Erlang/Elixir are mutually exclusive at this point, sadly. There are projects in progress that attempt to solve the distributed supervisors ideas -- Swarm, Firenest, Horde -- but even without that, any Erlang/Elixir app can go a long way before needing distributed coordination.