More benefit and practical example of distributed Erlang/OTP (simple) application

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

More benefit and practical example of distributed Erlang/OTP (simple) application

I Gusti Ngurah Oka Prinarjaya
Hi,

Again, my questions and confusions will base on Learn-You-Some-Erlang book. Yes, because i learn erlang from that book. And..thank you so much, Fred.

Now, i just finished read and practicing https://learnyousomeerlang.com/distributed-otp-applications part of the book. From this part, i learn how to develop a super simple distributed app that runs in 3 separated nodes. 

I have web service infrastructure experience. I've done several freelance projects related to improving availability and delivery speed. Mostly done by clustering web servers, database servers, distributing traffic to clustered web servers, routing write and read to clustered databases servers, etc. My tools such as NginX, MariaDB Galera, MariaDB MaxScale, HAProxy, etc.

If i try to compare what i learn in https://learnyousomeerlang.com/distributed-otp-applications with my experiences, i can't see the benefits of distributed erlang/otp app that explained in the book. Then my questions are:

1. Based on the book, i can't see the benefits by creating 2 backup nodes. Because there's no traffic distribution. Having 3 web-server machines then distributing traffic to them is more make sense for me for now. If 1 web-server failure, there's still 2 web-server left to serve.

2. Based on the book, service/module can execute at any nodes, but the service originally at the main / 1st node as long as the 1st node still alive. Service executed at 1st node. I can't see the benefits. Because in the end, it will only burden the 1st node. So what is the other 2 backup node is for? only act as a forwarder? The other 2 backup nodes are just "sitting", passive, doing nothing (except forwarding request) waiting for the 1st node to die.

3. I do really need to understand Erlang distributed programming, is there any more practical simple example? Yes, simple example, because if you ask me to read RabbitMQ's source code, that will make me drunk hahaha 😅

Please enlightenment

Thank you










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

Re: More benefit and practical example of distributed Erlang/OTP (simple) application

Tristan Sloughter-4
If i try to compare what i learn in https://learnyousomeerlang.com/distributed-otp-applications with my experiences, i can't see the benefits of distributed erlang/otp app that explained in the book.

And you are probably right.

There is an important note in that chapter:

Note: In terms of distributed programming fallacies, distributed OTP applications assume that when there is a failure, it is likely due to a hardware failure, and not a netsplit. If you deem netsplits more likely than hardware failures, then you have to be aware of the possibility that the application is running both as a backup and main one, and that funny things could happen when the network issue is resolved. Maybe distributed OTP applications aren't the right mechanism for you in these cases.

If you have a service that, for whatever reason (like not being a stateless service), you only can have 1 instance active at a time but you have additional nodes you can use as backups in case of hardware failure on the current active node then distributed applications are an answer.

Tristan

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

Re: More benefit and practical example of distributed Erlang/OTP (simple) application

Dániel Szoboszlay
In reply to this post by I Gusti Ngurah Oka Prinarjaya
Let me try to give you a simple example to illustrate the use of distributed applications. Let's say you have a website and you want it to serve with a cluster of N nodes. You need a web server application, and that should be really running on all the nodes (so it's not an OTP distributed application), so all of the nodes will be utilised. But you also have an application that sends out a daily newsletter of top articles or whatever to your users. It is not a good idea to start this application on all the N nodes independently, because each of them would independently send out the same email, so your users would get N copies of that. Sending the newsletter is a task that should be done on exactly one node in the cluster (but it doesn't matter on which one): this is the use case for distributed applications. It's not about distributing load across nodes, it is for electing a single node in a distributed system to perform some task that has to be performed only once.

But to be honest I wouldn't really recommend using distributed applications. They are very rarely used, and their implementation is not very robust. Practically, never try to have more than one distributed application in your release. (For those interested in the technical details: the dist_ac processes across the cluster run a protocol to decide where to start a distributed application. They can only run the protocol for one application at a time, and all the nodes have to participate in the protocol, so until a decision is made, they cannot handle requests to start an other application. Now let's imagine you have two distributed applications in your release, A and B (started in this order). If the node running B crashes and gets restarted by heart, the dist_ac processes may deadlock, because the newly restarted node would start running the protocol for A first, while the rest of the cluster is still running the protocol for B which has to be restarted somewhere after the crash.) There are better solutions for selecting a single node (or process) for doing a task only once in a cluster, such as gproc or global registered names.

Cheers,
Daniel

On Mon, 12 Aug 2019 at 17:38, I Gusti Ngurah Oka Prinarjaya <[hidden email]> wrote:
Hi,

Again, my questions and confusions will base on Learn-You-Some-Erlang book. Yes, because i learn erlang from that book. And..thank you so much, Fred.

Now, i just finished read and practicing https://learnyousomeerlang.com/distributed-otp-applications part of the book. From this part, i learn how to develop a super simple distributed app that runs in 3 separated nodes. 

I have web service infrastructure experience. I've done several freelance projects related to improving availability and delivery speed. Mostly done by clustering web servers, database servers, distributing traffic to clustered web servers, routing write and read to clustered databases servers, etc. My tools such as NginX, MariaDB Galera, MariaDB MaxScale, HAProxy, etc.

If i try to compare what i learn in https://learnyousomeerlang.com/distributed-otp-applications with my experiences, i can't see the benefits of distributed erlang/otp app that explained in the book. Then my questions are:

1. Based on the book, i can't see the benefits by creating 2 backup nodes. Because there's no traffic distribution. Having 3 web-server machines then distributing traffic to them is more make sense for me for now. If 1 web-server failure, there's still 2 web-server left to serve.

2. Based on the book, service/module can execute at any nodes, but the service originally at the main / 1st node as long as the 1st node still alive. Service executed at 1st node. I can't see the benefits. Because in the end, it will only burden the 1st node. So what is the other 2 backup node is for? only act as a forwarder? The other 2 backup nodes are just "sitting", passive, doing nothing (except forwarding request) waiting for the 1st node to die.

3. I do really need to understand Erlang distributed programming, is there any more practical simple example? Yes, simple example, because if you ask me to read RabbitMQ's source code, that will make me drunk hahaha 😅

Please enlightenment

Thank you









_______________________________________________
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