2 ms·
Let it crash, so that if something goes wrong, it does not do so silently. Let it crash, because a relevant manager will detect it, report it, clean it up, and
by nine_k 1y ago
Let it crash, so that if something goes wrong, it does not do so silently.
Let it crash, because a relevant manager will detect it, report it, clean it up, and restart it, without you having to write a line of code for that.
Let it crash as soon as possible, so that any problem (like a crash loop) is readily visible. It's very easy to replace arbitrary bits of Erlang code in a running system, without affecting the rest of it. "Fix it in prod" is better than "miss it in prod", especially when you cannot stop the prod ever.
- 0x445442 1y agoAre individual agents deployable on their own or does the entire "app" of agents need to be deployed as a single group? If individually deployable, what does this look like from a version control and a CI/CD perspective?
- nine_k 1y agoTo the best of my knowledge: yes, individual parts are deployable separately, within reason. No, there explicitly no need to deploy the whole thing at once, and especially to shut it down all at once. Erlang works by message passing and duck typing, so, as long as your interfaces are compatible (backwards or forwards), you can alter the implementation, and evolve the interfaces. Think microservices, but when every function can be a microservice, at an absolutely trivial cost.
- OkayPhysicist 1y agoConceptually, individual subtrees are deployable on their own. In practice, it generally makes sense to mark some subtrees as intended for individual deployment, creating what's known in the BEAM community (Erlang/Elixir/some other) as an "Umbrella app". Your umbrella app launches a tree of sub-apps, which are themselves subtrees. Depending on your view on monorepos, each individual sub-app could be its own repo, or just a subdivision of a single large repo. You basically take the same approach you would with microservices, but your orchestration is built into the language.