Separating Functionality

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Separating Functionality

Code Wiget
Hi everyone,

With many programming languages, it is easy to think of ways to separate projects into distinct micro services. With Erlang, I'm having trouble deciding on how to spread out functionality. Because the Erlang VM can run multiple different fully independent applications, it seems tedious to spin up 5 different Erlang VM’s to do different things when it could all be accomplished on one.

At the same time, as you scale, you probably want to separate functionality…

So, do you have a rule of thumb or rules by which you decide on how to separate functionalities into modules vs applications vs entire releases?

Thanks!

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Separating Functionality

Robert Raschke
The main equivalent of a microservice is what Erlang calls an "application". This is an entity that you are supposed to be able to start, stop and up/downgrade as a thing in its own right. And it may depend on other "applications", in turn it may be depended upon, or it can be independent or even just a stateless library. 

Multiple "applications" make up your system, called a "release" in Erlang. Whether your "applications" are distributed across multiple nodes or not is up to you. 

On Wed, 29 Aug 2018 19:50 Code Wiget, <[hidden email]> wrote:
Hi everyone,

With many programming languages, it is easy to think of ways to separate projects into distinct micro services. With Erlang, I'm having trouble deciding on how to spread out functionality. Because the Erlang VM can run multiple different fully independent applications, it seems tedious to spin up 5 different Erlang VM’s to do different things when it could all be accomplished on one.

At the same time, as you scale, you probably want to separate functionality…

So, do you have a rule of thumb or rules by which you decide on how to separate functionalities into modules vs applications vs entire releases?

Thanks!
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Separating Functionality

Robert Raschke
Further, a "module" is a code organisational thing, "applications" and similar OTP entities, like "supervisor", "gen_server "or "gen_statem", are runtime things.

Thus, an "application" is made up of a bunch of "modules" that implement either libraries of functions and/or processes that that do stateful work (usually implemented using "gen_..." frameworks).

On Wed, 29 Aug 2018 21:50 Robert Raschke, <[hidden email]> wrote:
The main equivalent of a microservice is what Erlang calls an "application". This is an entity that you are supposed to be able to start, stop and up/downgrade as a thing in its own right. And it may depend on other "applications", in turn it may be depended upon, or it can be independent or even just a stateless library. 

Multiple "applications" make up your system, called a "release" in Erlang. Whether your "applications" are distributed across multiple nodes or not is up to you. 

On Wed, 29 Aug 2018 19:50 Code Wiget, <[hidden email]> wrote:
Hi everyone,

With many programming languages, it is easy to think of ways to separate projects into distinct micro services. With Erlang, I'm having trouble deciding on how to spread out functionality. Because the Erlang VM can run multiple different fully independent applications, it seems tedious to spin up 5 different Erlang VM’s to do different things when it could all be accomplished on one.

At the same time, as you scale, you probably want to separate functionality…

So, do you have a rule of thumb or rules by which you decide on how to separate functionalities into modules vs applications vs entire releases?

Thanks!
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Separating Functionality

Fred Hebert-2
In reply to this post by Code Wiget
On 08/29, Code Wiget wrote:
>Hi everyone,
>
>With many programming languages, it is easy to think of ways to separate projects into distinct micro services. With Erlang, I'm having trouble deciding on how to spread out functionality. Because the Erlang VM can run multiple different fully independent applications, it seems tedious to spin up 5 different Erlang VM’s to do different things when it could all be accomplished on one.
>
>At the same time, as you scale, you probably want to separate functionality…
>
>So, do you have a rule of thumb or rules by which you decide on how to separate functionalities into modules vs applications vs entire releases?
>

My rule of thumb is always: How do I want this to fail?

Should the apps be independent from each other? Is one of them worth
running without the other? If they can't live without each other then
they're probably worth keeping on the same node.

Do they communicate heavily with each other?

The cost of talking over the network is higher than communicating over
the loopback interface, which is higher than message passing. This can
impact decisions.

Is one of the components unreliable?

If you got code talking to C or C++ programs that you don't necessarily
trust, or that the code itself is kind of risky, isolating it entirely
will allow to crash the whole VM of one app without hurting the others

What's their scaling factor?

If you have a stateless component serving lots of traffic for cheap
(such as a web front-end), splitting it from stateful parts that must be
treated more carefully may make sense; even put them on different
machines if you must.


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Separating Functionality

books
In reply to this post by Code Wiget
On Wed, Aug 29, 2018 at 10:50 AM Code Wiget <[hidden email]> wrote:
>
> Hi everyone,
>
> With many programming languages, it is easy to think of ways to separate projects into distinct micro services. With Erlang, I'm having trouble deciding on how to spread out functionality. Because the Erlang VM can run multiple different fully independent applications, it seems tedious to spin up 5 different Erlang VM’s to do different things when it could all be accomplished on one.

I wonder in Erlang terms of 'application',  if running multiple
applications in one single Erlang VM,   are there any ways to
configure resource restrictions to each application,  at OTP
Supervisor tree level  ?   like how much memory can it use at most,
and CPU, network, ... etc
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: Separating Functionality

Jesper Louis Andersen-2
Historically no.

At present, we can limit processes and their memory usage.

In extension of the excellent response by Fred, this is yet another reason as to why you might want to split your system. If parts of the system proves to be unreliable, or expected to be so, then isolate them.

On the other hand, Erlang systems are usually good at fair scheduling among processes, so if you can manage the memory pressure of the VM, it might be enough. 

On Fri, Aug 31, 2018 at 4:23 PM books <[hidden email]> wrote:
On Wed, Aug 29, 2018 at 10:50 AM Code Wiget <[hidden email]> wrote:
>
> Hi everyone,
>
> With many programming languages, it is easy to think of ways to separate projects into distinct micro services. With Erlang, I'm having trouble deciding on how to spread out functionality. Because the Erlang VM can run multiple different fully independent applications, it seems tedious to spin up 5 different Erlang VM’s to do different things when it could all be accomplished on one.

I wonder in Erlang terms of 'application',  if running multiple
applications in one single Erlang VM,   are there any ways to
configure resource restrictions to each application,  at OTP
Supervisor tree level  ?   like how much memory can it use at most,
and CPU, network, ... etc
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


--
J.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions