[erlang-questions] Embedded vs Interactive - Why embedded?

[Michael Truog]

On 03/09/2016 06:45 AM, Ryan Stewart wrote:
> # Quick Background
>
> I inherited an Erlang system that's a fairly typical HTTP, almost-ReST API. The nature of the API and what it represents made Erlang a good choice for its concurrency aspects. As for the reliability aspects, we rely totally on a typical HTTP/S load balancer setup for HA. We do rolling restarts behind the LB and not hot code upgrades as enabled by Erlang because of the complexity of Erlang upgrades.
>
> # The Question
>
> Why should we run embedded mode in production? It seems that's the unspoken law for production systems, but why? Is there some performance overhead running in interactive mode? I've read about Code Loading Strategy in the System Principles User's Guide:
> http://erlang.org/doc/system_principles/system_principles.html#id56789
>
> I've also read about the mode differences in the code server:
> http://erlang.org/doc/man/code.html
>
> I don't see anything in any of the stdlib/OTP docs about *why* you would choose embedded vs interactive mode. I'm leaning heavily toward using interactive mode everywhere, dev through production, because it's so much simpler and easy to understand. Someone please talk me out of it if that's a terribly Bad Idea.
>
> Ryan
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
My understanding is that embedded is preferred for any production use, to make sure the system will fail-fast upon startup if there are any problems loading dependencies.  The best time to have something fail is when it first starts, due to its lifetime being undefined and possibly infinite (ignoring heat death in the universe, and other natural disasters that should be written out of legal agreements :-).  Ideally this concept is extended into the runtime of the server, into initialization and configuration source code, to make sure the server can fail-fast upon startup when the server is misconfigured, rather than waiting an arbitrary number of hours or days to find out that a problem exists.  This approach helps to avoid a reliance on a fire-fighting mentality that becomes dependant on monitoring for feedback on a system's health due to the source code being a potentially unknowable black-box for some organizational reason.

The interactive mode helps when testing, since things are loaded automatically and you can have less concern about the dependencies, since you are actively creating or modifying the dependencies.  In production, you want an iron fist's control on all the dependencies, to make sure everything is repeatable and the service is stable, otherwise the development is pursuing stability in a serious way. So, that means that production usage should demand that all the dependencies come from a specific place at a specific version that is known and tracked, to be easily replicated, without any ambiguity.

Best Regards,
Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160309/41335c6e/attachment.htm>